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METHOD AND APPARATUS FOR PROVIDING TVrORTf k ATSm 
OTTTFH TN TERMITTENT CONNECTIVIT Y IN A C03MPUTING 

ENVIRONMENT 

FIELD OF THE INVENTION 

5 iThe present mventiori relates to comectivityiDelweennet^^ 

computing devices. More particularly, the present invention relates to 
methods and systems that transparently address the characteristics of 
nomadic systems, and enable existing network applications to run reliably in 
the associated mobile environments. Still more particularly, the invention 
10 relates to techniques and systems for providing a continuous data stream 
connection between intermittently-connected devices such as handheld data 
units and personal computing devices. ^ 

BACKGROUND AND SUMMARY OF THE INVENTION 

Increasingly, companies are seeing rapid access to key information as 
15 the way to maintaining a competitive advantage. To provide immediate 
access to this information, mobile and other intennittently-connected 
computing devices are quietly and swiftly becoming an essential part of 
corporate networks — especially with the proliferation of inexpensive 
laptops and hand-held computing devices. However, integratiiig these 
20 nomadic devices into existing network injErastructures has created a 
challenge for the information manager. 

Many problems in mobile networking parallel the difficulties in early 
local area networks (LANs) before the adoption of Ethernet. There are a 
variety of mobile protocols and interfaces, and because standards are just 
25 developing, there is little interoperability between systems. In addition, 
performance over these network technologies has typically been slow and 
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bandwidth limited. Implemeiitation costs to date have been high due the 
speciaHzed nature of deployed systemsv 

Along witli these issues, mobile teclinologies present a category of 
problems unto their pwn, InterGonnects back into the main network may 
5 travel over and through a public network infrastructui;e, thus allowing 

sensitive information to possibly be tapped into. Furthermore, if any of tlie 
intermediary interconnects are via a wireless interface, the information is 
actually broadcast, and anyone with a similar interface can eavesdrop 
without much difficulty. 

10 But, perhaps even m.pre significantly, rnobUe networking has 

generally in the past been limited to mostly message-oriented or stateless 
applications — and thiis has not been readily adaptable for existing or hew 
corporate applications that use client/server, host-terminalj web-based or 
shared file systems models. This is because such coinmonly used 

15 applications heed stateful sessions that employ a continuous stream of data - 
- not just a stateless packet exchange — to work effectively and reliably. 

To this end, many or most popular off-the-shelf networking 
applications require TCP/IP sessions, or private virtual circuits. These 
sessions cannot continue to function if diey encounter network 

20 interruptions, nor can they tolerate roaming between networks (i.e., a 

change of network addresses) while established. Yet, mobile networking is, 
by its nature, dynamic and unreliable. Consider these common scenarios 
encountered in mobile networks: 

Disconnected or Out of Range User 
25 When a mobile device disconnects firotn a given network or loses 

contact (e.g., through an outage or "hole" in the coverage of a wireless 
interconnect), the session-oriented application running on the mobile device 
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loses its stateful conuectiGn witii its peer aad ceases to operate. When the 
device is reattached or moves back into contact, the user must re-connect, 
log in again for security purposes, find the place in the appHcation where 
work was left off, and possibly re-enter lost data. This reconnection process 
5 is time consuming, Gostlyi and can be very frustrating. 

Moving to a Different Network or Across a Router Boundary (Network 
Address Change") 

Mobile networks are generally segmented for manageability 
purposes. But the intent of mobile devices is to allow them to roam. 

10 Roaming from one network interconnect to another can mean a change of 
network address. If tMs happens while the system is operational, tiie 
routing information must be changed for communications to continue 
between tlie associated peers. Furthermore, acquiring a new network 
address may require all of the previously established stateful application 

15 sessions to be terminated — again presenting the reconnection problems 
noted above. 

Security 

As mentioned before^ companies need to protect critical corporate 
data. Off-the-shelf enterprise applications are often written with the 

20 assumption that access to the physical network is controlled (i.e., carried 
within cables installed inside a secure facUity), and security is maintained 
through an additional layer of authentication and possible encryption. 
These assumptions have not been true in the nomadic computing world ~ 
where data is at risk for interception as it travels over public airways or 

25 public wire-line infrastructures. 



wo 02/23362 



4 



PCT/USOl/28391 



It would be highly desirable to provide an integrated solution that 
transparenliy addresses the characteristics of nomadic systems, and enables 
existing network applications to run reliably in these mobile environments. 
The present invention solves this problem by providing a seamless 
5 solution that extends the enterprise networl^ letting network managers 

provide mobile users with easy access to the same applications as stationary 
users without sacrificing reliability or centralized management. The 
solution combines advantages of present-day wire-Mne network standards 
with emerging mobile standards to create a solution that works with existing 

10 network applications. 

In accord^ce with one aspect of a non-limiting exemplary and 
illustrative embodiment of the present invention, a Mobility Management 
Server (MMS) coupled to the mobile interconnect maintains the state of 
each of any number of Mobile End Systems (MES) and handles the 

15 complex session management required to maintain persistent connections to 
the network and to peer application processes. If a Mobile End System 
becomes unreachable, suspends, or changes network address (e.g., due to 
roainjng from one network interconnect to another), the Mobility 
Management Server maintains the connection to the associated peer ~ 

20- aUowing the Mobile End System to mam 

connection even though it may temporarily lose its actual physical 
connection. 

The illustrative non-limiting example embodiments provided by the 
present invention also provide the following (among others) new and 
25 advantageous techniques and arrangernents: 

• a MobUity Management Server providing user configurable 
session priorities for mobile clients; 
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per-user mobile policy management for managing consumption 
of network fesoOTces; 

a roaming methodology maldiig use of the industry standard 
Dynamic Host Configuration R-otocol (DHGP) in coordination 
with a Mobility Managanent Sei^ 

automatic system removal of unreliable datagrams based on user 
configurable timeouts; and ^ 
automatic system removal of unreliable datagriams based on user 
configurable retries. 
10 In more detaH, the pref ^ 

invention in one of their aspects provide a Mobility Management Server that 
is coupled to the mobile interconnect (network). The Mobility Management 
Server maintains the state of each of any number of Mobile End Systems 
and handles the complex session management required to maintain 
15 persistent connections to the network and to other processes (e.g. j riiming 
on other network-based peer systems). If a Mobile End Systfeni becomes 
unreachable, suspends, or changes network address (e.g., due to roaming 
from one network interconnect to auoaier), the Mobility Management 
Server maintains the connection to the associated peer, by acknowledging 
20 receipt of data and queuing requests. This proxying by the Mobility 

Manageirieut Server allows the application on the Mobile End System to 
maihtadn a cofitintidu^ connection even thoiigh itmay temporarily lose its 
physical connection to a specific network medium. 
M accordance with arioth^ 
25 t>resent invention, a Mobihty j\lanageinerit Server 

Mobile End Systems. Each Mobile End System is provided with a proxy 
address on liie primary network. This highly avmlable address is known as 
tiie ^'virtual address" of the Mobile End System. The Mobility Management 
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Server maps the virtual addresses to eurrent "pQint of presence" addresses 
of the nomadic systems. "While the point of presence address of a Mobile 
End System may change when the mobile system changes from one network 
intercpmiect to Miother, tb^^ 
5 connections are active or longer if the address is statically assigned. 

Jn aecprdance with yet^other aspect of the preferred exemplary 
embodiments, of the present inventipn, a MobiUty Management Server 
provides centrahzed system management of Mobile End Systems tlirough a 
console application and exhaustive metiics.The preferred embodiment also 

10 prpyides user cpiifigurable sessippi priorities f or njoMe cHent^ running 
through a proxy server, and per-user mobile policy management for 
managing Gonsuinption of network resources. 

In accordance with yet another aspect, a Remote Procedure Call 
protocol and an Internet Mobility Protpcol are used to establish 

15 conmranicatipm between the proxy server and each Mobile End System. . 

Rempte procedure caUs provide a method foy allowing si. prpcess on a 
local system to invoke a procedure on a remote system. The use of the BPC 
prptpcpl allows Mobile End Systems to disconnect, go put of range or 
suspend pperation witiiput losing active network sessions. Since sessipn 

20 maintenance does not depend on a customized application, off-the-shelf 
applications wiU run without modification in the nomadic environment. 

The Reinote Procedure Gall protpcol generates transactions into 
messages that can be sent via the standard network transport protocol and 
infrastracture. These RPC messages contain the entire network transaction 

25 initiated by an application running on the Mobile End System— enabling 
the Mobility Management Server and Mobile End System to keep 
connection state information synchronized at all tunes -■- even during 
interruptions of the physical link connecting the two. In the preferred 
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embodiment of the present invention providing RPC's, the proxy server and 
the Mobile End Systems share sufficient knowledge of each transaction's 
state to maintain coherent logical database about all shared connectioins at 
all times. 

5 The Internet Mobility Protocol provided in accordance with the 

preferred embodiment of the present invention compensates for differences 
between wired local area network interconnects and other less reliable 
networks such as a wireless LAN or WAN. Adjusted frame sizes and 
protocol timing provide significant performance improvements over non- 
10 mobile-aware transports v- dramatically reducing network traffic; This is 
important when bandwidth is limited or when battery life is a concern. The 
Internet Mobility Protocol provided in accordance with the preferred 
embodiment of the present invention also ensures the security of 
organizational data as it passes between the Mobile End System and the 
15 Mobility Management Server over public network interconnects or airways. 
The iQtemet Mobility Protocol provides a baisic firewall function by 
allowing only authenticated devices access to the organizational network. 
The Internet Mobility Protocol can also certify and encrypt all 
cornmunications between the Mobility Managenient Server and the Mobile 
20 End System. , 

In accordance with yet another aspect of preferred non-limiting 
embodiments of the present invention, mobile inter-connectivity is built on 
standard transport protocols (e.g., TCP/IP, UDP/EP and DHCP, etc) to 
extend the reach of standard network application interfaces. The preferred 
25 exeniplary enibodhnents of ttie present invention efficientiy integrates 
transport, security, address management, device management and user 
management needs to make nomadic computing environments effectively 
transparent. The Internet Mobility Protocol provides an efficient 
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tnechaoism f or multiplexing multiple stireams of data (reliable and 
imreliable) through a single virtual channei provided by such standard 
, traQsport protoeols over standard network in&astructure. . 

With tbe help of the Ri*G layer, the Internet Mobihty Protocol 
5 Goalesce$ data from different sources targeted for the same or different 
destinatiohs* together into a single strpain aind forwards it over a niobile 
link. At the other end of themobile link, the data is demultiplexed back into 
multiple distinct streams, which are sent on tO' their ultimate destination(s). 
The multiplexing/demultipleidng techMque aUows^f^^^ 
10 available bandwidth (by generating the maximum sized network frames 
possible), and allows multiple channels to be established (thus allowing^ 
prioritization and possibly providing a guaranteed quality of service if the 
underlying network provides the service). 
The^^^^l^^ 

15 prefeired example enabodiments of the presen^^ 

additional non-UniitLng exemplary features and advantages: ^ . 

• ^Transport protocol independence. 

• Allows the hetwork point of presence (POP) or network 
: infrastracture to change without affe^ 

20 where physiical boundary, policy or limitations of bandwidtbi rnay 

apply). 

• Minimal additional overhead. 

• Automatic fragment resizing to accommodate the transmission 
medium, (When the protocol data unit for a givemfr 

25 greater then the available maximum transmission unit of the 

network medium, the Internet Mobility Protocol will fragment 
and reassemble the firame to insure that it can traverse the 
network. In the event of a retransmit, the jfirame will again be 
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assessed. If :the network infrastmcture or environment changes, 
the frame will be rejBragmented or in the case that the maximum 
transmission unit actually grew, sent as a single frame.) 
Semantics of unreliable data are preserved, by allowing frames to. 
discard unreliable data during retransmit. 

Provides anew semantic of Reliable DEitagranl service. (Delivery 
of datagrams can now be guaranteed to the peer terminus of the 

Internet Mobility Pi-otocol connection. Notification of delivery 
can be provided to a requesting entity.) 

Considers the send and receive trahsmiiision path separately, and 
automatically tailors its operating pairameters to provided 
optimum throughput (Based on hysteresis, it adjusts such 
parameters as frame size/fragmentation threshold, number of 
frames outstanding (window)i retransmit time, and delayed, 
acknowledgement time to reduce the amount of duplicate data 
sent through the network.) 

Network fault tolerant (since the expected usage is in a mobile 
environment, temporary loss of network medium connectivity 
does not result in a termination of the virtual channel or 
application based connection). 

Provides an.in-band signahng method to its peer to adjust 
operating parameters (each end of the connection can alert its 
peer to any changes in network topology or environment). 
Employs congestion avoidance algorithms and gracefully decays 
throughput when necessary. 

Employs selective acknowledgement and fast retransmit policies 
to limit the number of gratuitous retransmissions, and provide 
faster handoff recovery in nomadic environments. (This also 
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aUows the protocol to maintain optimmn^ to 
network environment.) 
» Employs sliding window technology to allow multiple frames to 
be outstanding. (This parameter is adjustable in each direction 
and provides for streaining firqmes up to a specified limit without 
, requiring an acknowledgement from its peer.) 

• Sequence numbers are not byte oriented, thus allowing for a 
single sequence number to represent up to a marimum 
size.' 

• Security aware. (Allows for authentication layer and encryption 
layer to be added in at the Internet Mobility Protocol layer.) 

• Compression to allow for better efficiency through bandwidth 
limited links. • 

• Balanced design, allowing either peer to inigrate to a new point of 
presence. 

• Either side may establish a connection to the peer. 

• Allows for inactivity tihieouts to be invpked to readily discard 
donnant connections aiidrecovea: expended resbtu^^ 

• Allows for a maximum lifetime of a given connection (e.g., to 
aUow termination and/6r refusal to accept cbnhections afte^ 
given period or time of day). 

Non-limiting preferred exemplaiy embodim^enfs of ^^^^ 
invention also allow a system aidmiiiistrator to nrahage consumption of 
network resources; For example, the system administrator can place 
controls on Mobile End Systems, the Mobihty Managenaent Server, or both. 
Such controls can be for the purpose, for example, of managing allocation 
of network bandwidth or other resources; or they may be related to security 
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issues. It may be most efficient to perform management tasks at the client 
side for cUents with lots of resources. However, thin clients don't have 
many resources to spare, so it may not be practical to burden them with 
additional code and processes for performing policy management. 
5 Accordingly, it may be most practical to perfonn or share such pbU^ 
management fiinctioiis for thin clients at a centralized point such as the 
Mobility Management Server. Since the Mobility Management Server 
proxies the distinct data streams of the Mobile End Systems, it provides a 
central point from which to conduct poUcy management. Moreover, the 

10 Mobility Management Server provides the opportuidly to perform poUcy 
mattagiBment of Mobile Eiid Systems on a per user and/or per device basis. 
SinceUie Mobility Management Server is proxymg on a per user basis, it 
has the abUity to control and limit each user's access to network resources 
on a per-user basis as well as on a per-device basis. 

15 As one simple example, the MobiUty Manageiment Server can ''lock 

out" certain users from accessitig certain network resources. This is 
especially important considering that interface network is via a mobile 
interconnect, and may thus "extend" outside of tlie boundaries of a locked 
organizational facility (consider, for example, an ex-employee who tries to 

20 access the network from outside his former employer's building). However, 
the policy management provided by the Mobility Management Server can 
be much more sophisticated. For example, it is possible for the Mobility 
Management Server to control particular Web URL's particular users can 
visit, filter data returned by network services requests, and/or compress data 

25 for network bandwidth conservation. This provides a way to enhance 
existibag and new appHcation-level services in a seamless and transparent 
manner. 
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. Furthemore, because the Mobile End System may 
an "imtrasted" network (i.e. outside the corporations locked boundaries) 
there is a chance of malicious attack while being remotely connected. By 
sharing policy rules and filters with the Mobile End System, one can protect 
5 flie MES from rogue connections, provide ingress filtering for the remote 
node, and further secure the corporate infrastructure from one central 
location. 

A further exemplary embodiment of the invention provides an 
interface-assisted roarning listener that allows Mobile End Systems to take 

10 advantage of interfaces supportipLg generic signaling, to enable interface- 
assisted roaming; In accordance with one feature provided in accordance 
with the exemplary embodiment, the Mobile End System interface-based 
listener determines in response to an event (e.g., a callback, a timer timeOut 
or a network activity hint indicating data loss), whether the Mobile End 

15 System's media connectivity status has changed. Fcmt example^ the listener 
signals to the interface when it detects that the Mobile End System has 
become detached and is no longer in communication with the network. 
Upon re-attachment, the listener uses previously recorded network point of 
attachment identification information to determine whether the Mobile End 

20 System has been reattached to the same or different network point of 

attachment. If the reattachment is to the same network point of attachment, 
the listener signals to alert the mobUe clients that they need to take steps to 
reestablish transport level communications. If the reattachment is to a 
different network point of attachment, the listener signals a "roam" 

25 condition and prompts the Mobile End System to acquire an address that is 
usable on the current network segment (this may entail, for example, 
registering the current address to be valid on a new subnet, for example). 
The listener may maintain a network topology map (which may be learned 
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through operation) to assist it in deciding the correct signal (e.g., "roani 
same subnet" or "roam") to generate todts clients. 

A stiB fiirfhet aspect provided by non-linaiting preferred exemplary 
embodiments of Our invention aUowis access to a Mobility Management 
5 Server (MMS) in a "disjoint networking" mode. The new algorithm allows 
for dynamic/static discovery of alternate lietwork addresses that can be used 
to establish/continue communications with an MMS r- even in a disjoint 
network topology in which one network infrastructtire may have no 
knowledge of network addresses for another network infrastructure. In 

10 accordance with this arrangement, a list of alternate addresses that the MMS 
is available at is preconfiguredi forwarded to or dynamically learned by an 
MES (Mobile End System) during the course of a conversation/connection: 
In one embodiment^, the MMS can use a connection over one network to 
send the MES one or more MMS network addresses or other MMS 

15 identities coif esponding to other networks. This list can be sent/updated 
during circuit creation or at any other time during the connection. 

If/when the MES roams to a second network; it uses the list of MMS 
"alias" addresses/identifications to contact the MMS over the new network 
connection on the second network. This allows the MES to re-establish 

20 contact with the MMS over the new network connection even though the . 
first and second networks may not share any addresses, routes, or other 
information. 

Further example embodiments of the invention provide policy 
management decision making within a distributed mobile netwoilc topology. 
25 For example, rule-based policy management procedures can be performed 
to allow, deny and/or condition request fulfillment based on a variety Of 
metrics. Such policy management can be used, for example, to provide 
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decision maMng based on cost metrics such as least cost routing in a multi- 
home/path environment. 

Such policy management techniques may take into account the issue 
of mobility or positioning (i.e., roaming) in making decisions. For example, 
5 poHcy management rules inay be based on locale of the de\ice (e.g.i 

proximity to network point of attachment such as access point/base station, 
hubs, routers, or GPS coordinate) so certain operations can be allowed in 
one building of an enterprise but not in another building. An example of 
such an applicatLon might be an enterprise with several different wireless 

10 networks. Such an enterprise might have a loading dock and office area 
sealed by a wireless network. The system adroinistrator would be able to 
configure the system such that workers (e.g., users aiid devices) on the 
loatting dock are not permitted access to the wireless network in the office 
environment. Also policy management results can be tri-^state: alio Wj deny 

15 or delay (for example, if the decision is based on bandwidth requirements or 
cost, the decision may be to delay an operation from being executed and to 
wait for a more opportune time when the operation can be accommodated), 

The policy management provided by the preferred example 
embodiments is capable of mocKfying an operation based on a decision. For 

20 example, one example action is to throttle consumption of network 
bandwidth for ail active applications. Also consider an aggressive 
apphcation that is consuming significant bandwidth. The policy engine can 
govern the rate at which the apphcation's operations/transactions are 
completed. TMs behavior may also be learned dynamically to squelch a 

25 possible errant application. Another example action provides reconstitution 
of data( i.e. dithering of graphics images based on available/allowable 
bandwidth or cost/user restrictions). 
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Furthermore the rules engine allows for other actions to be invoked 
based on rule evaluation. External procedures such as logging an event, 
sending an alert or notifying the user that the action is being denied, 
delayed, or conditioned may be executed. Such notification can also be 
5 interactive and ask for possible overrides to an existing rule from Hie 
operator. 

T^e poUcy management engine provided in the exaraple non- 
embodiment can base its decision making on any number or combination 
metrics that are associated with the device, device group, user group, 

10 user,/or network point of attachment. 

, As part of the poEcy management funetionalityi other locale base 
information and services may also be acquired/provided for the purposes of 
pohcy management, network modeling, and/or asset tracldng; Such services 
include the ability to automatically present to users and mobile end systems 

15 information that is appMcable within the context of a mobile 

present location. This information may be provided in the form of fnessages, 
files, or in some other electronic format. 

One non-limiting example of such use of this capability Would 
permit shopping mails, business CQinmuhities, and large retailers^ to locate 

20 wireless access points that miay be compatible witii Bluetooth PANs, IEEE 
802.11 LANs, 802.15 PANs, or other wireless network standards in 
strategic locations within the shopping center. As customers roam fipom 
location to location, stores and vendors would be permitted to push down 
information relevatit to the vendors that are present within the mobile end 

25 systems cixtreht location. This kiformatipn would include infonnatioii such 
as current sales, discounts, and services. In addition to sucbi information, 
mobile end systems may be provided electronic coupons used for sales 
promotion. Vendors would be permitted to register for these sennices 
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fhrough soine qentralized authority that may be associated with the mall, 
business community, retailer, or soine other hosted service. 

A further example non-limiting use of such a technology would be in 
vertical industries where inforniation is collected based on location 
5 including but not limite4 to such industries as field service, field sales, 
package delivery, or public safety where lists of local services, maps, 
directions, customers, or hazards may be pushed down to mobile end 
systems based on location. 

Yet another non^lirntting example use may entail a web based service 

.10 for monitoiing and tracking mobile end systems. For example^ custom.ers 
may register for this tracking service so trusted third parties may log onto 
the hosted web service and find oiit exact locations of their mobile end 
systems. This may include mobile end systems installed on vehicles or . 
cariiedl by pedestrians . As mobile end systems continue to experience 

15 reductions in. size and wait, such services become more likely. These 

services would perroit people to track and locate individuals that are high 
risk such as elderly, handicapped, or ill. It may also be used to track items 
that are highly valued such as automobiles or other expensive mobUe 
properties and packages. Using 3Q WAN networks, Bluetooth networks, 

20 802. 1 1 networks, 802. 15 networks ^ and other wireless technologies, 

combined with this unique ability to provide seamless connectivity while 
switching network mediums or point of attachments, such services become 
posisible and Kfcely at a inuch reduced cost. 

The present invention thus extends the enterprise network, letting 

25 network managers provide mobile users with easy access to the same 

applications as stationary users without sacrificing reliability or centralized 
management. The solution combities advantages of existing wire-Hne 
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network standards with emerging mobility standards to create a solution that 
works with existing network applications. 

BRIEF DESCRIPTION OF THE DRAWINGS 

These, as well as other features and advantages of this invention, will 
5 be more completely understood and appreciated by careful study of the 
following more detailed description of presently prefeiTed example 
embodiments of the invention taken in conjunction with the accompanying 
drawings, of which: 

Figure 1 is a diagram of an overall mobile computing network 
10 provided in accordance with tlie present invention; 

Figure 2 shows an example software architecture for a Mobile End 
System and a Mobility Management Server; 

Figure 2A shows example steps performed to transfer information 
between a Mobile End System and a MobiUty Mauagfement Server; 
15 Figm-e 3 shows an example mobile interceptor architectuj e; 

Figure 3A is a flowchart of example steps performed by the mobile 
interceptor; 

Figure SB is a flowchart of example steps performed by an RFC 
engine to handle RFC work requests; 
20 Figmes 4-5C are flowcharts of example steps to process RFC work 

requests; 

Figure 6 is a diagram of an example received work request; 

Figure 7 is a diagram showing how a received work request can be 
dispatched onto different priority queues; 
25 Figures 8 and 9 show processing of the contents of the different 

priority queues; 
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Figures 10A-15B show example steps performed to provide an 

Internet Mobility Protocol- 
Figure 16 shows example listener data structures; 
Figures 17, 17A and 18 are flowcharts of example steps performed to 
5 provide for mobile interconnect roaming; 

Figures 19 A and 19B are together a flowchart of an example 

interface-assisted roaming process; 

Figure 20 shows an example interface assisted roaming topology 

node data structiire; 
10 Figure 21 shows an example technique for distributing rhobiUty 

management system network addresses to mobile end systems in a disjoint 

network topology; ■ . 

Figure 22 shows an example nse of the Figure 21 technique to 

provide secure communications; 
15 Figure 23 shows an example use of the Figure 21 technique to 

provide network address translation in a distributed network interface 

scenario; 

Figure 24 shows an example policy management table; and , 
Figure 25 is a flowchart of example pohcy maiiagement processing 

20 steps 

DTCTAn.KH nTC SCRIPTION OF NON-LIMITING PRESENTLY 
PREFERRED EXAMPLE EMBODIMENTS 

Figure 1 is an example of mobile enhanced networked computer 
system 100 provided in accordance with the present invention. Networked 
25 computer system 100 includes a Mobility Management Server 102 and one 
or more Mobile End Systems 104. Mobile End Systems' 104 can 
communieate with Mobility Management Server 102 via a local area 
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network (LAJSO 108. MobiKly Management Server 102 serves as network 
level proxy for Mobile End Systems 104 by maintaining the state of each 
Mobile End Systemj and by handling the complex session management 
required to maintain persistent connections to any peer systems 110 that 
host network applications ~ despite the interconnect between Mobile End 
Systems 104 and MobiMtj Management Server 102 being intermittent and 
unreliable. In; the preferred embodiment^ Mobility IVlanagement Server 102 
comniunicates with Mobile End Systems 104 using Remote Procedure Call 
and Internet Mobility Protocols in accordance with the present invention. 

In this particular example,* Mobile End Ss^tems 104 are sometimes 
but not always actively conneeted to Mobility Management Server 102, For 
example: 

• Some Mobile End Systems 104a- 104k may communicate with 
Mobility Management Server 102 via a niobile interconnect 
(wirelessly in this case), e.g.j conventional electromagnetic (e.g., 
radio frequency) trausceivers 106 coupled to wireless (or wire-line) 
local aresi or wide area network 108 . Such mobile inteirconnect may 
allow Mobile End Systems 104a-104k to "roam" from one cover area 
107a to another coverage area 107k. Typically, there is a temporary 
loss of communications when a Mobile End System 1 04 roams from 
one coverage area 107 to another^ moves out of range of the closest 
transceiver 106, or has its signal temporarily obstructed (e.g., when 
temporarily moved behind a building coluron or the like). 

• Other Mobile End Systems 1041, 104m, ... niay communicate 
with Mdbihty Management Searver 102 via non-permanent wire- 
based intercormects 109 such as docldng ports^ network cable 
comiectors, or the like. There may be a temporary loss of 
communications when Mobile End Systems 104 are temporarily 
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discQimeGted from LAN 108 by brealqng connection 109* powering 
off the Mobile End Systems, etc. 

• Still other Mobile End Systems (e.g., lG4n) may be nomadically 

coupledto.MobilityManagementServer 102 viaafurthernetwork 

5 topography 111 such as a wide area network, a dial-up network, a 

satellite network, or the Intemetv to name a few examples. In one 
example, network 111 loayproAdde intermittent service. M; to . 
example. Mobile End Systems 104 may move from one type of 
cbimection to another (e.g. , from being connected to Mobility 
10 Management Server 102 via wire-abased itttercoim 

connected via network 1 11, or vice versa) — its coimection being 
temporarily broken during the time it is being moved from one 
connection to another. 

Mobile End Systems 104 may be standard mobile devices and off the 
15 shelf computers. For example, MpbUe End System 104 nmy comprise a 
laptop computer equipped with a conventional radio transceiver and/or 
network cards available from ia number of manufacturers. Mobile End 
Systems 104 may ruri standard network applications and a standard 
operating system, and communicate on the transport layer usiQg a 
20 conventionally available suite of transport level protocols (e.g., TGP/IP 

suite,) In accordance with the present invention, Mobile End Systems 104 
also execute client software that enables them to communicate with 
Mobility Management Servet 102 using Remote Procedure Call and Internet 
Mobility Protocols that are transported using the same such standard 
25 transport level protocols. 

Mobility Management Server 102 may comprise software hosted by 
a conventional Windows NT or other server. In the preferred embodiment, 
Mobility Management Server 102 is a standards-compKant, client-server 
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based intelligent server that transparently extends the enterprise network 
108 to a nomadic envuronment. Mobility Management Server 102 serves as 
network level proxy for each of any nxunber of Mobile End Systems 1 04 by 
maintaining the state of each Mobile End Systera, and by handling the 
5 complex session management required to maintaih persistent connections to 
any peer systems 1 10 that host network applications despite the mobile 
- intercoimect between Mobile End Systems 104 and transceivers 1 06 being 
intermittent and unreliable. 

For example, server 102 allows any conventional (e.g., TGP/IP 

10 based) network apjplicatioh to operate without rdodification over mobile 
connection. Server 102 naaiiitaiiis the sessions of Mobile Efiid Systems 104 
that discoimect, go out of range or suspend Operation; and resunies the 
sessions when the Mobile End System returns to service. When a Mobile 
End System 104 becomes unreachable, shuts down or changes its point of 

15 presence address, the Mobility Management Server 102 maintains the 
connection to the peer system 1 10 by acknowledging receipt of data and 
queuing requests until the Mobile End System once again becomes 
available and reachable. 

Server 102 also extends the management capabilities of wired 

20 networks to mobile connections. Each network software layer operates 
independently of others, so the solution can be customized to the 
environment where it is deployed. 

As one example. Mobility Management Server 102 may be attached 
to a conventional organizatibnal network 108 such as a local area network 

25 or wide area network. Network 108 may be connected to a variety of fixed- 
end systems 1 10 (e.g., one or most host computers 110), Mobility 
Management Server 102 enables Mobile End Systems 104 to communicate 
with Fixed End System(s) 110 using continuous session type data streams 
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even though Mobile End Systems 104 sometimes lose contact with their 
associated network interconnect or move from one network interconnect 
106, 109, 1 1 1 to another (e.g., in the case of. wireless interconnect, by 
roaming from one wireless transceiver 106 coverage area 107 to another). 
5 A Mobile End System 104 establishes an association with the 

Mobility Management Server 102, either at startup or when the Mobile End 
System requires network services. Once this association is established, the 
Mobile End System 104 can start one or more network application sessions, 
either serially or concurrently. The Mobile End System 104-to-Mobility 

10 Management Server 102 association allows the MobUej End System to 
maintain application sessions when the lyiobileiEnd System, disconnects, 
goes out of range or suspends operation, and resume sessions when the 
Mobile End System returns to service. In the preferred embodiment, this 
process is entirely automatic and does not require any intervention on the 

15 user's part. 

In accordance with an aspect of the present invention, Mobile End 
Systems 104 communicate with Mobility Management Server 102 using 
conventional transport protocols such as, for example, UDP/IP. Use of 
conventional transport protocok aUows Mobile End Systems 104 to 

20 communicate with Mobility Management Server 102 using the conventional 
routers 112 and other infirastracture already existing on organization's 
network 108, In accordance with the present invention, a higher-level 
Remote Procedure Call protocol generates transactions into messages that 
are sent over the mobile enhanced network 108 via the standard transport 

25 protocol(s). In this preferred embodiment, these mobile RPG messages 

contain the entire network transaction initiated by an application running on 
the Mobile End System 104, so it can be completed in its entirety by the 
Mobility Management Server. This enables the Mobility Management 
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Server 102 and Mobile End System 104 to keep connection state 
information synchronized at all titnes — even during interruptions of 
network medium connectivity. 

Each of Mobile End Systems 104 executes a mobility management 
5 software client that supplies the Mobile End System with the intelligence to 
intercept aU network activity and relay it via the mobile RPG protocol to 
Mobility Management Server 102. In the preferred embodiment, the 
mobility management client works transparently with operating system 
features present on Mobile End Systems 104 (e.g., Windows NT, Windows 

10 98, Windows 95^ Windows CE^ etc.) to keep client-site application sessions 
active when contact is lost with the network. 

Mobility Management Server 102 maintains the state of each Mobile 
End System 104 and handles tbe complex session management required to 
maintain persistent connections to associated peer 1 08 such as host 

15 computer 1 10 attached to the other end of the Connection end point. If a 
Mobile End System 104 becomes unreachable^ suspends, or changes 
network address (e.g., due to roaming from one network interconnect to 
another), the Mobility Management Server 1 02 maiatains the comiection to 
the host system 1 10 or other connection end-point, by acknowledging 

20 receipt of data and queuing requests. This proxy function means that the 
peer application never detects that the physical connection to the Mobile 
End System 104 has been lost - allowing the Mobile End System's 
application(s) to effectively maintain a continuous connection with its 
associated session end point (by simply and easily resuming operations once 

25 a physical connection again is established) despite the mobile system 

temporarily losing connection or roaimng from one network interconnect 
106A to another network interconnect 106K within coverage area 107K. 
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MobiHty Management Server 102 also provides address managem 
to solve the problem of Mobile End Systems 104 receiving different 
network addresses when they roam to different parts of the segmented 
network. Each Mobile End System 104 is provided with a virtual address 
5 on tlje primary network. Standard protocols or static assignment determine 
these virtual addresses . For each active Mobile End System 104, Mobility 
Management Server 102 maps the virtual address to the Mobile End 
System's current actual ("point of presence") address. Wliile the point of 
presence address of a. Mobile Bud System 104 niay change when the device 

10, . changes from one network segment to anothery the virtual address stays 
constant while any connections are active or longer if the address is 
assigned statically. 

Thus, the change of a point of presence address of a Mobile End 
System l64 remains entirely transparent to an associated session end point 

15 on host system 1 10 (or other peer) communicating with the Mobile End 
System via the Mobility Management Server 102. The peer 110 sees only 
the (unchanging) virtual address proxied by the server 102. 

In the preferred embodiment, Mobility Management Sei-ver 102 can 
also provide centralized system management through console applications 

20 and exhaustive metrics. A system adininistrator can use these tools to 
configiure and manage remote connections, and troubleshoot remote 
connection and system problems. 

The proxy server function provided by Mobility Management Server 
102 allows for different priority levels for network applications, users and 

25 machines. This is useful because each Mobility Management Server 1 02 is 
composed of finite processing resources. Allowing the system manager to 
configure the Mobility Management Server 102 in this way provides 
enhanced overall system and network performance. As one example, the 
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system manager can configure Mobility Management Server 102 to allow 
real time applications such as streaming audio or video to have greater 
access to the Mobility Management Server 102's resources than other less 
denianding applications such as email. 
5 In more detail. Mobility Management Server 1 02 can be configured 

via an application or appUcation interface; standard network mahkgenlent 
protocols such as SNMP;; a Web-based configiiratidii interface; or a local 
user interface. It is possible to configure association priority and/or to 
configm-e appHcation priority withitt an association. For exainple, the 

10 priority of each associatidn relatiYe to other associations running^^t^ 
the Mobihty Management Server 102 is cbjofiprable by ei^ 
name, or machine name (in the preferred^iembodimeiitj when the priority is 
configured for both the user and the machine that a user is logged in on, the 
configuration for the user may have higher precedence). In addition or 

15 alternatively, each association inay have several levels of application 
priority, wMch is configured based on networfc^ The 
sj^tem allows for any number of priority levels to exist. In one particular 
implementattoh, three priority; levels are provided: low, medium and high. 

Sierver and Client Example Software Architecture 
20 Figure 2 shows an example software architecture for Mobile End 

System 104 and Mobility Management Seryer 102, In accordance with one 
aspect of the present invention. Mobile End System 104 and Mobility 
Management Server 102 run standard operating system and application 
software ~ with only a few new components being added to enable reliable 
25 and efficient persistent session connections over an iutermittenfly connected 
mobile network 108. As shown in Figure 2, Mobile End Systena 104 runs 
conventLpnal operating system software including network interface drivers 
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200, TCP/UDP tra»sport support 202, a transport driver interface (TDI) 
204i and a socket API 206 used tp interface with one or more conventional 
network applications 208. Conventional network file and print services 210 
may also be provided to communicate with conventional TPI 204. Server 
5 102 may include similar conventional network interface drivers 200', 
TCP/UDP transport support 202', a transport driver interface (TDI) 204', 
and a socket API 206' used to interface with one or more conventional 
network applications 208'. Mobile End System 104 and Mobility 
Management Server 102 may each further include conventional security 

10 software such as a network/s0c\nity provider 236 (Mobile End System) and 
a user/security database 238 (server). . 

In accordance with the present invention, a new, mobile interceptor 
component 212 is inserted between the TCP/UDP tiansport module 202 and 
the transport driver interface (TDI) 204 of the Mobile End System 104 

15 software architecture. Mobile interceptor 212 intercepts certain calls at the 
TDI 204 interface and routes them via RPC and Internet MobiHiy Protocols 
and the standard TCP/UDP transport protocols 202 to Mobility^ 
Management Server 102 over network 108. Mobile interceptor 212 thus 
can intercept all network activity and relay it to server 102. Interceptor 212 

20 works transparenfly with operating system features to allow client-side 
application sessions to remain active when the Mobile End System 104 
loses contact with network 108 

¥/]-iile mobile interceptor 212 could operate at a different level than, 
the traaiisp<»t <Mva^ 

25 are advaudtagfes in having moMe interceptor i2i^ operate at the TDI level or 
more specifically, any transport protocol interface. For brevity sake, all 
references to the tiansport driver interface will be denoted using the 
acronym TDI. Many conventional operating systems (e.g., Microsoft 
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Windows 95, Windows 98, Windows NT and Windows CE, etc. ) provide 
TDI interface 204 ~ thus providing compatibilily without any need to 
change operating system components. Furthermorej because the transport 
driver interface 204 is normally a kernel level interface, there is no need to 
5 switch to user mode ~ thus realizing performance improvements. 

Furthermore, mobile interceptor 212 working at the level of TDI interface 
204 is able to intercept from a variety of different network applications 208 
(e.g., multiple simultaneously running applications) as weU as 
encompassing network file, print and other kernel mode semces 210 

10 (which would have to be handled differently if the interceptor operated at 
the socket API level 206 for example). 

Figure 2A shows an example Mgh leveLflowchart of how mobae 
interceptor 212 works. A call to the TDI interface 204 of Mobile End 
System 104 (block 250) is intercepted by mobile interceptor 212 (block 

15 252). Mobile interceptor 212 packages the intercepted RFC caU in a 

fragment in accordance with an Internet Mobility Protocol, and sends the 
fragment as a datagram via a conventional transport protocol such as UDP 
or TCP over the LAN, WAN or other transport 108 to Mobility 
Management Server 102 (block 252). The Mobility Management Server 

20 102 receives and unpackages the RFC datagram (block 254), and provides 
the requested service (for example, actmg as a proxy to the Mobile End 
System apphcation 208 by passing data or a response to a application server 
process running on Fixed End System 110). 

Referring once again to Figure 2, Mobility Management Server 102 

25 includes an address translator 220 that intercepts messages to/from Mobile 
End Systems 104 via a conventional network interface driver 222. For 
example, address translator 230 recognizes messages from an associated 
session peer (Fixed End System 1 10) destined for the Mobile End System 
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104 virtual address. These incoming Mobile End System messages are 
provided to proxy server 224, which then maps the virtual address and 
message to previously queued transactions and then forwards tlic responses 
back to the current point of presence addresses being used by the associated 
5 Mobile End System 104. 

As also shown in Figure 2, Mobility Management Server 102 
includes, in addition to address translation (intermediate driver) 22G, and 
proxy server 224, a configuration manager 228, a control/user interface 230 
and a monitor 232. Configuration management 228 is used to provide 
10 configuration inforrnation and parameters to aH 

manage connections. Control, user interface 230 and monitor 232 allow a 
user to interact with proxy server 224. 

Mobile Interceptor 

Figure 3 shows an example software architecture for mobile 
15 interceptor 212 that support the RFC Protocol and the Internet Mobihty 
Protocol in accordance with the present invention. In this example, mobile 
interceptor 212 has two functional components: 

a Remote Procedure Call protocol engine 240; and 
an Internet Mobility Protocol engine 244. 
20 Proxy server 224 running on Mobility Management Server 102 provides 
corresponding engiues 240', 244". 

Mobile interceptor 212 in the preferred embodiment thus supports 
Remote Procedure Call protocol and Internet Mobility Protocol to connect 
Mobility Management Server 102 to each Mobile End Systems 104. 
25 Remote procedure calls provide a method for allowing a process on a local 
system to invoke a procedure on a remote system. Typically, the local 
system is' not aware that the procedure call is being executed on a remote 
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system. The use of RPC protocols aUows Mobile End Systems 104 to go 
out of range of suspend operation vidtbiout losing active network sessions. 
Since session maintenance does not depend on a customized application, 
o&the-shelf appUcations wiU run without modification in the mobile 
5 envirorunentofiietWoiklOS. 

NetworK applications typically use appIieationrleVel interfaces such 
as Windows socketis. A single call to an appUcation4e^ 
several outgoing or incoming data packets at the transport, or media access 
layer. In prior mobile, networks, if one of these packets is lost, the state of 
10 the enlkc connection may become 

dropped. In the preferred embodiment of the present invention providing 
RPGs, the Mobihty^M 

104 share sufficient knowledge of the connection state to maintain a; 
coherent logical link at all times — even during physical interruptioh. 

15 The Internet Mobility Protocol provided in accordance with the 

preserit invention cQmpehsates for 'differences between wire-line and other 
less reliable networks such as wireless. Adjusted frame sizes aiid protocol 
timing provide significant performance improvements over non-mobile- 
aware transports ~ dramatically reducing network traffic. This is important 

20 when bandywdth is 1^ 

The Intemet Mobility Protocol provided in accordance with the 
present invention also ensure the security of organization' s data as it passes 
between the Mobile End System 104 and the Mobility Management Server 
102 on the pubhc wiire^hne networks or airway. The Internet Mobility 

25 Protocol provides a basic firewaU function by allowing only authenticated 
devices access to the organizatipnal network. The Internet Mobility 
Protocol can also certify and encrypt all communications between the 
mobility management system 102 and the Mobile End System 104. 
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The Remote Procedure Gall protocol engine 240 on Mobile End 
Systeno. 104 of Figure 3 marshals TDI call pariMieters, fonnats the data, 
sends the request to the Internet Mobility Protocol engine 244 for 
forwarding to Mobility Management Server 102 where the TDI Remote 
5 Procedure Call engine 240' executes the calls, Mobile End Systems 104 
martial TDI call parameters according to the Remote Procedure Call 
protocol. When the Mobility Management Server 102 TDI Remote 
Procedure Call protocol engine 240' receives these RPCs, it executes the 
calls on behalf of the Mobile Bad System 104. The Mobiliiy Management 

10 Server 102 TDI Remote Procedure Call protocol engine 240* shares the 
complete network state for each connected Mobile End System with the 
peer Mobile End System 104's RPC engine 240. M addition to perfbrm^ 
remote procedure calls on behalf of the Mobile End Systems 104, the server 
RPC enguQe 240' is also responsible for system flow control, remote 

1 5 procedure call parsing, virtual address multiplexing (in coordination with 
services provided by address translator 220), remote procedure call 
transaction prioritization, scheduling, policy enforcement, and coalesding. 

The Intemet Mobility Protocol engine 244 performs reliable 
datagram sersntces, sequencing, fragpientation, and re--assembly of 

20 messages. It can, when configured, also provide authentieation, 

certification, data encryption and conipression for enhanced privacy, 
security and throughput. Because the Intemet Mobihty Protocol engine 244 
funetioiis in power^sensitive enviroiiments using several different 
transports, it is power management aware and is transport independent. 

25 Figure 3A shows an example process mobile interceptor 212i^^^ 

performs to communicate a TTDI call to Mobility Management Server 102. 
Generally, the mobile interceptor RPC protocol engine 240 forwards 
marshaled TDI calls to the Internet Mobility Protocol engine 244 to be 
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transinitted to the Mobility Management Server 102. RPC protocol engine . 
240 does tliis by posting the RPG caU to a queue maintained by the In^ 
Mobility Protocol engine 244 (block 302). To facilitate bandwidth 
management, the Internet MobiUty Protocol engine 244 delays sending 
5 received RPC calls for isome period of time (''the RPG coalesce time out 
period") (block 304). Typically, the RPG coalesce timeout is set between 
five and fifteen milliseconds as one example but is user configurable. This 
delay allows the RPG engine 240 to continue posting TDI calls to the 
Internet Mobility Protocol engine 244 queue so that more than one RPG call 

10 can be transmitted to the Mobility Management Server 102 in the same 
datagram (fra^ent). 

Wben the coalesce timer ejqpireSi or the RPG protocol engin^^^ 
determines that it will not be receiving more RPG calls (decision block 
306), the RPC engine provides the Internet Mobility Protocol engine 244 

15 witii a request to flush the queue, coalesce the RPG calls into a single firai^ 
and forward the frame to its peer (block 308). This coalescing reduces the 
number of transmissions — enhancing protocol performance. However, the 
Internet Mobility Protocol may also decide to flush queue 244 based on 
other external criteria to fiirther optimize performance. In the preferred 

20 erhbodiment, if a single RPG request wiU fiU an entire frame, the IMP layer 
will automatically try to send the request to the peer. 

As mentioned above. Mobility Management Server 1 02 proxy server 
also has an RPC protocol engine 212' and an Internet Mobility Protocol 
engine 244'. Figure 3B shows an example process performed by Mobility 

25 Management Seryer 102 upon receipt of an Internet Mobility Protocol 
message frame from Mobile End System 104. Once the frame is received 
by the Mobility Management Server 102, the Internet Mobility Protocol 
engme 244' reconstructs the frame if fragmented (due to the maxmium 
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transmission size of tlie underlying transport) and then demultiplexes the 
contents of the message to determine which Mobile End System 104 it was 
received from. This demultiplexing allows the Internet Mobility Protocol 
-244' to provide the Remote Procedure Call engine 240' with the correct 
5 association- specific context information. 

The Internet Mobility Protocol engine 244' then formulates the 
received message into a RPC receive indication system work request 354, 
and provides the Mobility Management Server 102 RPC engine 240' with 
the formulated work request and association-specific context information. 

10 When RPC protocol engine 240' receives work request 352, it places it into 
an association-specific work queue 356, and schedules the association to 
run by providing a scheduled request to a global queue 358. The main work 
thread of RPC engine 240' is then signaled that work is available. Once the 
msm thread is awake, it polls the global queue 358 to find the previously 

15 queued association scheduled event. It then de-queues the event and beings 
to process the association-specific work queue 356. 

On the association specific work queue 356 it finds the previously 
queued RPC receive indication work request The rttain'thread then de- 
queues the RPC receive indication work request 356 and parses the request. 

20 Because of the coalescing described in connection with Figure 3A, the 

Mobility Management Server 102 often receives several RPC transactions 
bundled in each datagram. It then demultiplexes each RPC transaction back 
into distinct remote procedure calls and executes the requested function on 
behalf of Mobile End System 104. For perfonhance pmposes RPC engine 

25 240' may provide a look ahead mechanism during the parsing process of the 
RPC messages to see if it can execute some of the requested transactions 
cohcmxently (pipelining). 
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How RFC Protocol Engine 240' Rims RFC Associations 

Figure 4 is a flowchart of an example process for running RPG 
associations placed on an association work queue 356. When an RPC 
association is scheduled to run, the main thread for the RPC protocol engine 
5 240' (which may be implemented as a state machine) de-queues the work 
request from global work queue 358 and determines the type of work 
request. 

There are six basic types of RPC work requests in the preferred 
embodiment: 
10 • schedule request; 

• • connect indication 

• disconhect indication 

• local terminate aissociatidn 

• "resources iavailabie" request; and 
15 • ping inactivity timeout. 

RPC protocol engine 240' handles these various types of requests 
differently depending upon its type. RPC protocol engine 240' tests the 
request type (indicated by inforiiauation. associalted with the request as stored 
on global queue 358) in order to detetmine how to process the request. 

20 If the type of work request is a "schedule request" (decision block 

360), the RPC engine 240' determines which association is being scheduled 
(block 362). RPC engiae 240' can determine this information from what is 
Stbred on global qudue 358. Once the association is known, RPC engine 
240' can identify the particular one of association work queues 356(1) ... 

25 356(n) the corresponding request is stored on. RPC engine 240 retrieves the 
correspohdmg association control block (block 362), and calls a Process 
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Association Work task 364 to begin processing the work in a specific 
association's work' queue 356 as previously noted. 

Figure 5 shows example steps performed by the "process association 
work" task 364 of Figure 4. Once the specific association has been 

.5 deterrained, this "process association work" task 3(64 is called to process the 
work that resides in the correspCHiding association work queue 356. If the 
de-queued work request (block 390) is an RPC receive request (decision 
block 392), it is sent to the RFC parser to be processed (block 394). 
Otherwise, if the de-queued work request is a pending receive request 

10 (decision block 396), the RPC engine 240' requests TDI 204' to start 

receiving data on behalf of the application's connection (block 398). If the 
de-queued work request is a pending connect request (decision block 400), 
RPC engine 240' requests TDI 204' to issue an application specified TCP 
(or other transport protocol) connect request (block 402). It then waits for a 

15 response from the TDI layer 204' . Once the requesit is completed by TDI 
204' , its status is determined and then reported back to the original 
requesting entity. As a performance measure, RPC engine 240' may decide 
to retry the connect request process some number of times by placing the 
request back on the assopiations-specific work queue (356) before actually 

20 reporting an error Ipack to the requeslmg peer. Ttiis agjain is done in an effort 
to reduce network bandwidth and processing consumption. 

The above process continues to loop until a "scheduling weight 
complete" test (block 404) is satisfied. In this example, a scheduling weight 
is used to decide how; many work requests will be> de7queijed ^d processed 

25 for this particular association. This scheduling weight is a configuration 
parameter set by configuration manager 228, and is acquired when the 
association connect indication occurs (Figure 4, block 372). This value is 
configurable based on user or the physical identification of the machine. 
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Once the RPC engine is finished with the association work queue 
356 (for the tiiae at least)j it niay pirGceed to process dispatch queues (block 
406) (to be discussed in more detail below). If, after processing work on 
the association's work queue 356, naore work remains in the Association 
5 work queue, the RPG engine .2^^ reschedule the association to run 
again at a latOT tune by posting a hew schedule request to tihe global work 
queue 358 (Figure 4^ decision block 366, blpck 368; Figure 5, decisio 
block 408, block 410). 

Referring once agam to Figure 4^ 
10 "comeetii^^ 

requested to instantiate a new association witii a mobile peer (usually, but 
not always, the Mobile End System 104). As one example, the connect 
. indication may provide the RPC engine 240' with the following information 
about the peer Jiiacbine which k^i^ 
15 • physical identifier of the machine, 

• name of the user logged into the machine j 

• address of the peer machine, and 

• optional connection data from die peer RPC engine 240. 

In response to the connect indication (decision block 370), the RPC 
20 engine 240 calls the configuration naanager 228 with these parameters. 
Configuration manager 228 uses these parameters to determine the exact 
configuration for the new connection. The configuration (e.g., association 
scheduling weight and the Hst of aU apphcations that require non-default 
scheduling priorities along with those priorities) is ^^t^^ the RPC 

25 engine 240' for storage iand execution. RPC engine 240' then starts the new 
association, and creates a new association control block (block 372). As 
shown in Figure 5 A the following actions may be taken; 

• allocate an association control block (block 372A); 
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® iniliaHze system wide respiu-ces witi^^ 
® get configuration ovemdes with curre^^ 
(bk>ck372C); 

• initialize flags (block 372D); . 

5 • initiaHze the association-specific work queue (^^ 

• initialize association object hash table (block 372F); 

• initialize the coalesce timer (block 372G); and 

• insert association control block into session tablet (bldck 372H). 
A "disconnect indication" is issUesd by the Mterjaet MoiDUity Protocol 

10 engine 244' to the RPG engine 240' when the Internet MdbiUty Protocol 
engine has determined that the association must be terminated. The RFC 
engine 240' tests for this disconnect indication (block 374), and in response, 
stops the association and destroys the association control block (block 376). 
As shown in Figure 5B, the foUoWhig steps niay be performed: 

15 • mark the association as deleted toi prevent any further processing 

of work that may be outstanding (block 376A); 

• close all associated assoeiaition objects including process, 
connection and address objects (block 376B); 

• free edl elements on work queue (block 376C); 
20 • stop coalesce! timer if running (block 376D); 

• decrement association control blbck refeirehce cduiit (block 
m6B)-am : ■\ - • 

• if the reference count is zero (tested for by block 376F): 
destroy association specific work queue, 

25 • destroy object hash table, 

• dejstroydoaleisce tuner, 

• remove association control block frond association table, and 
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• free control block (376G). 

A "termiilate session" request is issued when system 102 has 
determined tliat the association must be terminated. This request is issued 
by the system administrator, the operating system or an appUcation. RPG 
5 engine 240' handles a terminate session request in the same way it handles a 
disconnect request (decisidn block 378, block 376). 

In the preferred embodiment, the interface between the RPC engine 
240' and the Internet MobiUty Protocol engine 244' specifies a flow control 
mechanism based on credits. Each time one thread posts a work request to 

10 another thread, the called thread returns the number of credits left in the 
work queue. When a queue becomes fuU, the credit count goes to zero. By 
convention, the calling thread is to stop postmg further work once the credit 
count goes to zero. Therefore, it is necessary to have a mechanism to tell 
the calling thread that "resources are available" once the queued work is 

15 processed and more room is available by some user; eoiifigutable/pre- 
detennined low-water mark in the queue. This is the purpose of die 
"resources available" work indication (tested for by decision block 380). As 
shown in Figure SCj the following steps may be performed when the Ciredit 
count goes to zero: 

20 • mark association as "low mark pending" by setting the 

RPC_LMPQ_SEND_FLAG (block 379A). Once in this state: 

• all received datagrams aie discarded (block 379B); 

® all received stream events are throttled by refusing to accept the 
data (block 379C) (this causes the TCP or other transport receive 
25 window to evenmaUy close, and provides flow control between 

. the Fixed End System 110 and the Mobihty Management Server 
102; before returning, the preferred embodiment jams a "pending 
receive request" to the frcmt of the association specific work 
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queue 356 so that outstanding stream receiye event processing 
will continue immediately onee resources are made available). 
• all received connect events are refused for passive Goimections 
(block 379D). 

5 When the Resources available" indication is received by the RPG 

engine 240' (Figure 4, decision block 380), the RPC engine determine 
whether the association has work pending in its associated association work 
queue 356; if it does, the RPC engine marks the queue as eligible to run by 
posting the association to the global work queue 358 (block 382). If a 

10 pending receive request has been posted during the time the association was 
in the low mark pending state, it is processed at this time (in the preferred 
embodiment, the RPC engine 240 'continues to accept any received connect 
requests during this processing). 

Referring once again to Figure 4, if RPC engine 240' determines that 

15 the Mobility Management Server 102 channel used for "ping" has been 
inactive for a specified period of time (decision block 384), the channel is 
closed and the resources are freed back to the system to be used by other 
processes (block 386). . ' 

RPC Parsing and Priority Queuing 

20 Referring back to Figure 5, it was noted above that RPC engine 

pacrsed an RPC receive request upon receipt (see blocks 392, block 394). 
Parsing is necessary in the preferred embodiment because a single received' 
datagram can contain multiple RPC calls, and because RPC calls can span 
multiple Internet Mobility Protocol datagram fragments. An example 

25 format for an RPC receive work request 500 is shown in Figiu'e 6. Each 
RPC receive work request has at least a main fragment 502(1), and may 
have any number of additional fragments 502(2) .... 502(N). Main fragment 
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502(1) contains tiie work request structure header 503 and a receive overlay 
504. The receive overlay 504 is a structure overlay i)laGed on top of the 
fragment 502( 1 ) by the Internet Mobility Protocol engine 244. Within this 
overlay 504 is a structure member called pUserData that points to the first 
5 RPG call 506(1) witiun the work request 500. 

The Figure 6 exainpie illustrates a work request 500 that contains 
several RPC caUs 506(1), 506(2). 506(8)/ As s^^ 
example, an RPC work request 500 need not be contained in a contiguous 
block of memory or in a single fragment 502. In the example shown^ a 
10 second fragment 502(2) and a third fragment 502(3) that are chained 
together to tiie main^fr 

Thus, RPC jparser 394 in this exaiEiple handles the following 
boundary conditions: 

• each RPC receive request 500 may contain one or more RPC 
15 . •. calls; 

• one or more RPC calls 506 may exist in a single fragment 502; 

• each RPC call 506 may exist completely contained in a fragment 
502; and 

• each RPC call 506 may Span more llian one fragment 502. 

20 Figure 7 shows an example RPC parser process 394 to parse an RPC 

receive work request 500. In this example, the RPC jparser 394 gets the first 
fragment 502(1) in the work request, gets the first RPC call 506(1) in the 
fragment, and parses that RPC call. Parser 394 proceeds through the RPC 
receive work request 500 and processes each RPC caU 506 m turn. If the 

25 nuniber of fragment bytes remaining in the RPC receive workrequest 500 
fragment 502(1) is greater than the size of the RPC header 503, parser 394 
determines whether the RPC call is fuUy contained witMn the RPC fragment 
502 and thus may be processed (fihis maty be determined by testing whether 
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the RPG caU length is greater than t^^^^ ' 
remaining). If the RPC call type is a chain exceptioni then the RPC call will 
handle the updating of the RPC parser 394 state. In the proxy server 224, 
the only RPC calls using the chain exception are the "datagram send" and 

5 "stream.send" calls. This chain, exception procediure is done to stUpw the 
RPG engine to avoid fcagment copies by chaining merppry descriptor lists 
together for the purpose of RPC send calls. 

Once the parser 394 identifies an RPC call type, a pointer to the 
beginning of the RPG urformation is passed to the RPC engine 240 for 

10 execution; The RPC engine divides all XDI propejdure calls into different 
priorities for execution. PChe highest priority qalls are irnmediately executed 
by passing them to an RPG dispatcher 395 for imrnediate execution. All 
lower priority calls are dispatched to dispatch queues 510 for future, 
processing. Each dispatch queue 510 represents a discrete priority. 

15 In the preferred embodiment, mobile applications call the "open 

address" object land "open connection" pbject ftinctipns befpre executing 
other TDI netwprking functipns. Therefore, the systein assigns application 
level priorities during the "open address" object and "open connection" 
object calls. In the example enjbpdiment, once an address or connection 

20 pbject is assigned^a. priority, aU calls ttiat are asspqiated with that object are 
executed within that assigned priprity.^ 

If, for example, the RPC call is a TDI Open Address Object request 
or a TDI Open Connection Object Request, it is sent to the RPC dispatcher 
395 for immediate exe^sution, The ppeu A^^ps^ smd Opm ^Dpiinectipn 

25 object RPC csdls provide access tp a process ID or process nanie that are 
used to match against the information provided by the configurati.p^ 
manager 228 during the configuration requests that occurs within the 
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association connect indication described earlier. This is used to acquire 
configuration for the address or coimection objesct. 

In the preferred embodiment, all RFC calls have at least an address 
-Object or connection object as a parameter. When the call is made, the 
5 priority assigned to that specific object is used as the priority for the RFC 
call. The configwation assigned to the address or connect!^ 
determines which priority all associated RPG calls wiM be executed in. For 
example, if the assigned priority is "high," all RFC calls wiU be executed 
irmnediately without being dispatched to a dispatch queue 510. If the 
10 assigned priority is "1," all RPG caUs wiU be placed int»^ dispatch queue 

■ ■ •■: 510(1). - 

Referring once again to Figure 5, once the "process association 
. work" task 364 process has completed executing its scheduled amount of 
association work (decision block 404), it checks to see if liie dispatch 
15 queues require Servicing (block 406). Figure 8 is a flowchart of example 
steps performed by the "process dispatch queues" block 406 of Figure 5 to 
process the dispatch queues 510 shown in Figure 7. 

• In this example, dispatch queues 510 are processed beginning with 
the highest priority queue (510(1) in this example) (block 408). Each queue 
20 5 10 is assigned a weight factor. The weight factor is a configuration 

parameter that is returned by the configuration manager 228 when a Mobile 
End System 104 to MobiUty Management Server 102 association is created. 
As one example, low priority dispatch queues 510 can have a weight factor 
of 4, and medium priority queues can have a weight factor of 8. High 
25 priority RFC calls do not, in this example, use weight factors because they 
are executed iromediately as they are parsed. 

RFC engine 240' loops through the de-queuing of RFC calls from 
tihe current queue until either the queue is empty or the queue weight 
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number of RPG calls has been processed (blocks 412-416). For each de- 
queued RPC call, the RPC dispatcher 395 is called to execute flie call. The 
RPG dispatcher 395 executes the procedural call on behalf of the Mobile 
End System 104, and formulates the Mobile End System response for those 
5 RPG calls that require responses. 

If, after exiting the loop, the queue still has work remaining (decision 
block 418), the queue will be marked as eligible to run again (block 420). 
By exiting the loop, the system yields the processor to the next lower 
priority queue (blocks 424, 410). This ensures that all priority levels are 

10 given an opportunity to run no naatter how much work exists in any 

particular queue. The system gets the next queue to service, and iterates the 
process until aU queues have been processed. At the end of processing all 
queues, the system tests to see if any queues have been marked as eligible to 
rim -T and if so, the association is scheduled to run again by posting a 

15 schedule request to the global work queue. The association is scheduled to 
run again in the "process global work" routine shown in Figure 4 above. 
This approach yields the processor to allow other associations that have 
work to process an opportunity run. By assigning each queue a weight 
factor, the system may be tuned to allow different priority levels unequal 

20 access to the Mobility Management Server l02's GPU. Thus, higher 

priority queues are not only executed first, but may also be tuned to allow 
^ greater access to the CPU. 

MobiMtv Management Server RPC Responses 

The discussion above explains how remote procedure calls are sent 
25 from the Mobile End System 104 to the MobUily Management Server 102 
for execution. In addition to this type of RPG caM, the Mobility 
Management Server 102 RPG engine 240' also supports RPG events and 
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RPG receive responses. These are RPG messages that are generated 
asynchronously as a result of association specific coilnection peer activity 
(usually the Fixed End System 110). Mobility Management Server 102 
KPC engine 240' coinpletes RPG transactions that are executed by the RPG 
5 dispatcher 395. Not all RPG calls require a response on successful 
completion. Those RPG calls that do require responses oh successful 
completion cause the RPC dispatcher 395 to build the appropriate response 
and post the response to the Internet Mobile Protocol engine 244' to be 
returned to the peer Mobile End System 104. All RPG calls generate a 
10 response when the RPC call faMs (the RPG receive response is the exception 
to above). 

RPG events originate as a result of network 1 08 activity by the 
association specific connection (usually the Fixed End System 110). These 
RPC event messages are, in the preferred embodiment, proxied by the 
15 Mobility Management Server 102 and forwarded to the MobOe End System 
104. The preferred embodiment MobiUty Management Server 102 supports 
the following RPC event calls: 

• Disconnect Event (this occurs when association-specific 
connected peer (usually the Fixed End System 1 10) issues a 

20 transport level disconnect request; the disconnect is received by 

the proxy server 224 on behalf of the Mobile End System 1 04, 
and the proxy server then transmits a disconnect event to the 
Mobile End System); 

• Stream Receive Event (this event occurs when the association- 
25 specific connected peer (usually the Fixed End System 110) has 

sent stream data to the Mobile End System 104; the proxy server 
224 receives this data oh behalf of the Mobile End System 104, 
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and sends the data to the MpbUe End System m 
Receive Response); 
® Receive Datagram Event (this event occurs when any association- 

specific portal receives datagrams from a network peer (usually 

5 the Fixed End System ! 10) destmed for the Mobile End System 

104 through the Mobility Management Server 102; the proxy 
server 224 accepts these datagrams on behalf of the Mobile End 
System, and forwards them to the Mobile End System in the form 
of receive datagram events; and 
10 • Connect Event (tMs event occurs when the association-specific 

listening portal receives a transport layer connect request (usually 
from the Fixed End System 1 10) when it wishes to establish a 
transport layer end-to-end connection with a Mobile End System 
104; the proxy server 224 accepts the connect request oh behalf 
15 of the Mobile End System, and then builds a connect eivient RFC 

call andiorwards it to the Mobile End System). 
Figure 9 shows how the RFC engine 240' handles proxy server- 
generated RFC calls. For high priority address and connection objects, the 
RFC engine 240' dispatches a send request to the Internet Mobility Protocol 
20 engine 244' immediately. Tlie send request results in forwarding the RFC 
message to the peer Mobile End System 104. For lower priority objects, die 
Internet Mobility Protocol engine 244 send request is posted to an 
appropriate priority queue 510'. If the association is not scheduled to run, a 
schedule request is also posted to the global queue 358'. The Internet 
25 ■ Mobility Protocol send request is finally executed when the dispatch queues 
dre processed as described earlier in connection with Figures 5 & 8. 
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Example Internet Mobility Protocol 

Internet Mobility Protocol provided in accordance with the present 
invention is a message oriented connection based protocol. It provides 
guaranteed delivery, (re)order detection, and loss recovery. Further, unlike 
5 other conventional concaection oriented protocols (i.©; TGP)i it allows for 
multiple distinct streams of data to be combined over a single channel; and 
allows for guaranteed, unreliable, as well as new message oriented reliable 
data to traverse the network through the single virtual channel 
simultaneously. This new message oriented level of service can alert the 

10 requester when the Internet Mobility Protocol peer has acknowledged a 
given program data unit. 

The Internet Mobility Protocol provided in accordance with the 
present invention is designed to be an overlay on existing network 
topologies and technologies. Due to its indifference to the underlying 

15 network architecture, it is transport agnostic. As long as there is a way for 
packetized data to traverse between two peers, Internet Mobility Protocol 
can be deployed. Bach node's network point of presence (POP) or network 
infrastructure can also be changed without affecting the flow of data except 
where physical boundary, policy or limitations of bandwidth apply. 

20 With the help of the layer above, Internet Mobility Protocol 

, coalesces data from many sources and shuttles the data between the peers 
using underlying datagram facilities. As each discrete unit of data is 
presented from the upper layer, Internet Mobility Protocol combines into a 
single stream and subsequentiy submits it for transrnission. The data units 

25 . are then forwarded to the peer over the existing network where upon 

reception, with the help from the layer above, the stream is demultiplexed 
back into multiple distinct data units. This allows for optimum use of 
available bandwidth, by generating the maximum sized network frames 
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possible for each new txansimssion. IMs also hs^ &e Mded b^ 

training the channel once for ma^dmiifli bandwidth utilization and have its 

parameters applied to all session level connections. 

In rare instances where one channel is insufficient, the Internet 
5 Mobility Protocol further allows multiple channels to be established 
between the peers -- thus allowing for data prioritization and possibly 
pro\dding a guaranteed quahly of service (if the underlying network 
provides the service). 

The Internet Mobility Protocol also provides for dynamically 

10 selectable guaranteed or piff sejyicer ^W^^^^^^P^ 

protocol data unit that is submitted for transmission cm b^^ 
either a validity time period or a number of retrammit attempts or both. 
Intemet Mobilily Protocol wiU expire a data unit when either threshold is 
reached, and remove it from subsequent transmission attempts. 

15 Intemet Mobility Protocol's additional protocol overhead is kept, 

minimal by use of variable lenglh header. The frame type and any optional 
fields determine the size of the header. These optional fields are added in a 
specific order to enable easy parsing by the receiving side and bits in the 
header flag field denote their presence. All other control and configuratipn 

20 infomaation necessary for the peers to communicate can be passed through 
the in-band control channel. Any control information that needs to be sent is 
added to the frame prior to any application level protocol data unit. The 
receiving side processes the control inforination and then passes the rest of 
. the payload to the upper layer. 

25 Designed to run over relatively unreliable network links where the 

error probabihty is relatively high, Intemet Mobility Protocol utilizes a 
number of techniques to insure data integrity and obtain optimum network 
performance. To insure data integrity, a Fletcher checksum algorithm is 
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used to detect eirant frames. TMs algorithm was selected due to the fact of 
its efficiency as well as its detection capability. It can determine not only bit 
enors, but also bit reordering. However, other alternate checksum 
algoritlims maybe used in its place; 
5 Sequence numbers are used to insure ordered delivery of data. 

Internet Mobility Protocol sequence numbers do not, however, represent 
each byte of data a:s in TCP. They represent a frame of data that can be, in 
one example implementation, as large ais 65535 bytes (including the Internet 
Mobility Protocol header). They aie 32 bits or other convenient length in 

10 one example to insure that wrap-around does not occur over high bandwidth 
liiiks in a Umited amount of tLine. 

Combining this capability along with the expiration of data, 
retransmitted (retried) frames may contain less information than the 
previous version that was generated by the transmitting side. A frame id is 

15 provided to enable detection of the latest verisioned frame. However, since 
data is never added in the preferred embodiment attd each el^ 
is an entire protocol data unit, this is not a necessity for sequence assurance. 
In one example, the Internet Mobility Protocol will only process the first 
instance of a specific frame it receives — no matter how many other versions 

20 of that fraiiie are transmitted. Each frame created that carries new User 
payload is assigned its own uiiique sequeiiee number. 

Perforniance is gained by using of a sKcfiiig window^ 
allowing for more then one frame to be outstanding (transmitted) at k time 
before requiring the peer to acknowledge reception of the data. To insure 

25 timely delivery of the data, a positive acknowledgement and timer baked 
retransmit scheime is used. To further optimize the use of the channel, a 
selective acknowledgement ihechanismis employed that allows for fast 
retransmission of missing frames and quick recovery during losjsy air 
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congested periods of network ponneetivity. lii one examplej this seleetive ' 
aclmowledgement mech^anismis represented by an optional bit field that is 
included in the header. 

A congestion avoidance algorithni is also included to aHo^ 
5 protocol to back off from rapid retransmission of frames. For example, a 
round trip time can be calculated for each frame that has successfully 
transfer between the peers without a retransimt. This time value is averaged 
and then used as the basis for the retransmission timeout value. As each 
frame is sent ^ a timeout is established for that frame. If an ackjiowledgement 
10 for that frame is not received, and the frame has actually been transmitted, 
the frame is resent. The timeout value is then increased and then used as the 
basis for the next retransmission time. This retransmit time-out is bounded 
on both die upper and Ipwer side to insure that the value is vwithin a 
reasonable range. 

15 Internet Mobility Protocol also considers the send and receive patiis 

separately. This is especially useful on channels that are asymmetric in 
nature. Base on hysteresis, ttie Internet Mobility Protocol automatically 
adjusts parameters such as frame size (fragmentation threshold), number of 
frames outstanding, retransmit time, and delayed acknowledgement time to 

20 reduce the amount of duphcate data sent liirough the network: 

Due to the fact that Internet Mobility Protocol allows a node to 
migrate to different points of attachment on diverse networks, 
characteristics (e.g., frame size) of the underlying network may change 
midstream. An artifact of this migration is that frames that have been 

25 queued for transnussion on one network rnay no longer fit over the new 
medium the mobile device is currently attached to. Combining this issue 
wjtli the fact that fragmentation may not be supported by all network 
infrastructures, fragmentation is dealt with at the Internet Mobility Protocol 
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level. Before each frame is subioitted for transmissi^ 
Protocol assesses whether or not it exceeds the current ffagmehtataon 
thireshold. Note that this value may bes less than the curtent maximum 
transmisaon uriit for perfoimajace reason (smaller frames have a greater 
5 lilcelihdod of reaching its ultimate destLnation liien larger fraines). The 
tradeoff between greater protocol overhead versus laore retr£msmissions is 
weighed by Inteniet Mobility Protocol, and the frame size ihay be reduced 
in an attempt to reduce overall retransmissions). If a given frame will fit, it 
. is sent in its entirety. If not, the frame is sphtinto m:aximiuii aUbwable size 

10 for the given connection. If the frame is retransmitted, it is reassessed, and 
will be refiragmented if the maximum transmission imit has been rediiced (or 
alternatively, if the maximu^^ transrnissioh unit actiially grew, the frame 
may be resent as a single frame without fragmentation). 

The protocol itself is orthogonal in its design as either side may 

15 estabUsh or terminate a connection to its peer. In a particular 

implement^ afew minor operatipnal. differences, 

in the protocol engine depending on where it is running. For example, based 
on where the protocol engine is running, certain inactivity detection and 
connection lifetime timeouts may be only invoked on one side. To allow 

20 administrative control, Internet Mobility Protocol engine running on the 
Mobility Management Server 102 keeps track of inactivity periods. If the 
specified period of time expires without any activity from the Mobile End 
System 104, the Mobility Management Server 102 may terminate a session. 
Also, an adnainistrator may want to limit the overall time a particular 

25 connection may be established for, or when to deny access base on time of 
day. Again these poUcy timers may, in one example implementation, be 
invoked only on the Mobility ManagementServer 102 side. 
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In one example implementation, the software providing the Internet 
Mobility Protocol is compiled and executable under Windows NT, 9x, and 
CE environments with no platform specific modification. To accomplish 
this, Internet Mobility Protocol en^loys the services of a network 
5 abstraction layer (iS[AL) to send and reieeive Internet Mobilily Protocol 
framesi Other standai-d utility functions such as memory loana 
queue and list management, event logging, alert system, power 
management, security, etc are also used. A few runtime parameters are 
modified depending on whether the engine is part of a Mpbile End System 
10 104 or Mobihty Management Server 102 $ystenL Some examples of fW 
' ■ ■ ■ are: ■ . -V 

• Certain tiineouts are Only invoked on the Mobility Management 
Server 102 

• Direction of frames are indicated within each frame header for 
15 echo detection 

• Inbound Cdiinections may be denied if Mobile End Systeah 104. is 
so configured 

® Alerts only signaled on Mobility Management Server 102 

• Powermanagemerit enabled on Mobile End Systeui 104 but is not 
20 necessary on the Mobility Management Server 102 

The Internet Mobility Protocol interface may have only a small 
nuraber of "C" callable platform independent published API functions, and 
requires one O/S specific functioii to schedule its work (other then the 
aforementioned standard utility functiom). Gonuhunications with local 
25 clients is achieved through the use of defined work objects (\york reijuests). 
Efficient notification of the completion of each work element is 
accomplished by signaling the requesting entity through the optional 
completion callback routine specified as part of the work object. 
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The Intemet MobiEty Protoepl engine itself is queue based. Work 
elements passed from local clients are placed on a global work queue in 
FIFO order. This is accomphshed by local clients calling a pubUshed 
Intemet Mobihty protocol function such as "ProtocolRequestwork()". A 
5 scheduling ftinction inside of Internet Mobility Protocol then removes the 
work and dispatches it to the appropriate function. Combining the queuing 
and scheduling mechanisms conceal the differences between operating 
system architectures — allowing the protocol engine to be run under a 
threaded based scheme (e.g., Windows NT) or in a synchronous fashion 

10 (e.g., Microsoft Windows 9x & Windows CE). A priority scheme cah be 
overlaid on top of its queuing, thus enabling a guaranteed quality. of service 
to be provided (if the underlying network supports it). 

From the network perspective, the Intemet Mobihty Protocol uses 
scatter-gather techniques to reduce copying or movement of data. Each 

15 trahsmission is sent to the NAL as a list of fragments, and is coalesced by 
the network layer traiisipdrt. If the transport prbtocol itself supports scatter- 
gathef, the fragment list is passed through die transport and asseinbled by 
the media access layer driver or hardware. Furthermore, this technique is 
extensible in tliat it allows the insertion or deletion of any protocol wrapper 

20 at any level of the protocol stack. Reception of a frame is signaled by tihe 
NAL layer by calling back Internet Mobility Protocol at a specified entry 
point that is designated duiihg the NAL registration process. 

Example Intemet Mobility Protocol Engine Entry Points 

Internet Mobihty Protocol m the example embodiment exposes four 
25 common entry points that control its startup and shutdown behavior. These 
procedures are: 

1. Intemet Mobihty ProtocolCreateO 
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2. Internet Mobility ProtocolRunO 

3. Internet Mobility ProtocolHaltO 

4. Internet Mobilily ProtocolUnloadO 

Example Internet Mobility ProtoeolCreateO 
5 The Internet Mobility ProtoeolCreateO function is called by the boot 

subsystem to initialize the Internet Mobility Protocol. During ibis first 
phase, all resource necessaiy to start processing work must be acquired and 
initialized. At the completion of this phase, the engine must be in a state 
ready to accept work from other layers of the system. At this point, Internet 
10 Mobility Protocol initializes a global configuration table. To do this, it 
employs the services of the Configuration Manager 228 to popnlate the 
table. 

Next it registers its suspend and resume notification functions with 
the APM handler. In one example, these functions are only invoked pn the 

15 Mobile End System 104 side ~ but m another implementation it might be 
desirable to aUow Mobility Managenient Server 102 to suspend during 
operations. Other working storage is then allocated from the memory pool, 
such as the global work queue, and the global NAL portal list. 

To limit the maximum amount of runtime memory required as well 

20 as insuring Internet Mobility Protocol handles are unique, Internet Mobihty 
Protocol utihzes a 2-tier array scheme for generating handles. The 
globalCormectionArray table is sized based on the maximum number of 
simultaneous connection the system is configured for, and allocated at this 
time. Once all global stosrage is allocated and initialized, the global Internet 

25 Mobility Protocol state is change to _STATE_IM1TIALIZE_. 
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Example Internet Mobility ProtocolRiinO 

The Ihtemet Mobility ProtocolRimQ function is called after all 
subsystems have been initialized, and to alert the Internet Mobility Protocol 
subsystem that it is okay to start processing any queued work. This is the 
5 nonnsd state that the Internet MobiHty Protocol engine is dur^ 

operations. A few second pass initialization steps are taken at this point 
before placing the engine into an operational state, 

Internet Mobility Protocol allows for network communications to 
occur over any arbitrary interface(s). During the initialization step, the 
10 storage for the interface betweeh Jnter^ iandiNAL was 

allocated. Mternet MobiHty Protocol now walks through the global portal 
list to start aU listeners at the NAL. In one example, thds is comprised of a 
two step process: 

• Internet Mobility Protocol requests the NAL layer to bind and 
15 open thei portal based on coiifigwation supplied during 

initialization time; and 

• IntemetMobility Protocol then notifies the NAL layer that it is 
ready tp start processing received frames by registering the 
Internet Mobility ProtocolRCVFROMCB call back. 

20 • A local persistent identifier (PID) is then initialized. 

The global Internet Mobility Protocol state is change to 
_STATE_RUN_, .. . 

Example Internet Mobility ProtocnlTfalt 

The Mernet Mobihty ProtocpIHaltO function is called to alert the 
25 engine that the system is shuttuig doWn. AU resources acquired during its 
operation are to be release prior to returning from tins function. All Internet 
Mobility Protocol sessions are abnormally terminated with the reason code 
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set to administrative. No fiirther work is accepted froin. or posted to other 
layers once the en^^e has entered into _STA1^JEIALTED_ state. 

Example Internet Mobflitv ProtocolUnloadO 

The Internet Mobility ProtocolUnloadO function is the second phase 
5 of .the shutdown process. This is a last chance for engine to release any 

allocated system resources still being held before returning. Once the engine 
has returned from this function, no further work will be executed as the 

system itself is t erminating 

Example Mtemet Mobility Protocol handles 

10 In at least some examples, using just the address of the memory 

(which contains the Internet Mobility Protocol state information) as the 
token to describe an Internet Mobility Protocol connection inay be 
insufficieiit. This is miainly diie to possibility of one connection terminating 
and a new one starting in a short period of time. The probability that the 

15 memory allocator will reassign the same address for different connections is 
high ~ and this value would then denote both the old connection and a new 
connection. If the origitiai peer did not hear the termination of the session 
(i.e. it was off, suspended, out of range, etc.)j it could possibly send a frame 
on the old session to the new coimection. This happens in TCP and will 

20 cause a reset to be generated to the new session if the peer' s IP addresses 
are the same. To avoid this scenario, Internet Mobility Protocol uses 
manufactured handle. The handles are made up of indexes into two arrays 
and a nonce for uniqueness. The tables are laid out as follows. 

Table 1 : an array of pointers to an array of connection object 

25 Table 2 : an array of comiection objects that contains the real 

pointers to the Internet Mobility Protocol control blocks. 
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This teehmque jniniioizes the amount of memory being allocated at 
initializaliGn time. Table 1 is sized and allocated at startup. On the Mobile 
End System 104 side this allows allocation of a small amount of meniory 
inemory allocation required for this Table 1 on the Mobility 
5 Management Server 102 side is somewhat larger since the sesrver can have 
many connections). 

Table 1 is then populated on demand; When a connection request is 
, issued, Jntemet Mobility Protocol searches through Table 1 to find a valid 
pointer to Table 2. If no entries are found, then Internet Mobility Protocol 
10 will allocate a new Table 2 with a maximum of 256 connection, objects - 
and then stores the pointer to Table 2 into the appropriate slot in Table 1. 
The pi^otoeol engine then initializes Table 2, aUocates a boruifecti^ 
from the newly created table, and returns the mariufactured hkiidle. If 
aJiolliear ses^iola is requested, Internet Mobility Protocol will search Table 1 
15 once again, find the valid pointer to Table 2, and allocate the next 

connection object for the session. This goes on until one of two situations 
exist: ' ' ■ ' "'•■^ ■ '-^ 

• If all the connection objects arc exhausted in Table 2, a new 
Table 2 will be allocated, initialized, and a pointer to it wiU be 

20 placed in the next available slot in Table 1 ; and 

• If all connection objects have besen released for a specific Table 2 
instance and all elements are unused for a specified period of 
time, the storage for that instance of Table 2 is released back to 
the memory pool and the associated pointer in Table 1 is zeroed 

25 to indibate that that entry is now availafcle for use when tbei next 

conhectibri request is started (if and only if no other conneb^ 
object are available in other instances of Table 2). 
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Two global comiters are maintained to allow limiting the total 
nuniber of eonneetions allocated. One global coiinter counts the number of 
current active connections; and the other keeps track of the number of 
unallocated connection objects. The second counter is used to govern the 
5 total number of connection object that can be created to some arbitraiy 
limit. When a new Table 2 is allocated, this counter is adjusted downward 
to account for the number of objects the newly allocated table represents. 
On the flip side, when Internet Mobility Protocol releases a Table 2 instance 
back to the memory pool, tibie counter is adjusted upward with the number of 
10 connection objects that are being released. 

Example Work jBlow 

Work is requested by local clients through the Inteiiiet Mobility 
PrptocpIRequestWorkO function. Once the work is validated acid placed on 
the global work queue, the Internet Mobility ProtocolWorkQueueEli^ible() 

15 function is invoked. If in a threaded environment, the Mternet Mobility 
Protocol worker thread is signaled (marked eligible) and control is 
immediately returned to tide calling entity. If in a synchronous environment, 
the global work queue is immediately run to process apy work that was 
requested. Both methods end up executing the Internet Mobility 

20 ProtocolProcessWorkQ function. T^s is the naain dispatching function for 
processing work. 

Since only one thread at a time may be dispatching work from the 
global queue in the example einbpdinient, a global semaphore may be used 
to protect against reentraacy. Private Internet Mobility Protocol work can 

25 postworkdirectly to. the global work ^(^^ 
Mobility ProtoQolRequestWorkO ftmction. 
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A special case exists for SEND type work objects. To insure that tiie 
semantics of Unreliable Datagrams is kept, each SEND type work object 
can be queued with an expiry time or with a retry count. Work will be aged 
based on the expiry time. If the specified timeout occurs, tlie work object is 
5 removed from the coiuiection specific queue, and is completed with an error 
status. If the SEND object has already been coalesced into the data path, the 
protocol allows for tlie removal of any SEND object that has specified a 
retry count. Once the retry count has been exceeded, the object is removed 
from the list of elements that make up the specific frame, and then returned 
10 to the requestor with the appropriate error status. 

Example Connection Startup 

Internet Mobihty Protocol includes a very efficient mechanism to 
establish connections between peers. Confirmation of a connection can be 
determined in as little as a three-frame exchange between peers. The 

15 initiator sends an IMP SYNC frame to alert its peer that it is requestmg the 
establishment of a connection. The acceptor will either send an IMP 
ESTABLISH frame to confirm acceptance of the connection, or send an 
IMP ABORT frame to alert the peer that its connection request has been 
rejected. Reason and status codes are passed in the IMP ABORT frame to 

20 aid the user ia deciphering the reason for the rejection. If the connection 
was accepted, an acknowledgement frame is sent (possibly including 
protocol data unit or control data) and is forwarded to the acceptor to 
acknowledge receipt of its establish frame. 

To further minimize network traffic, the protocol allows user and 

25 control data to be included in the initial handshake mechanism used at 

connection startup. This ability can be used in an insecure environment or in 
environments where security is dealt with by a layer below, such that the 
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Internet Mobility Protocol can be tailored to avert the performance penalties 
due to double security authentication and encryption processing being done 
over the same data path. 

Example Data transfer 
5 Internet Mobility Protocol relies on signaling from the NAL to detect 

when a frame has been delivered to the network. It uses this metric to 
determine if the network link in question has been momentarily flow ' 
controlled, and will not submit the same frame for retransmission until the 
original request has been completed. Some network drivers however lie 

10 about the transmission of frames and indicate delivery prior to submitting 
them to the network. Through the use of senoaphores; the Mternet Mobility 
Protocol layer detects this behavior and only will send another datagrani 
until the NAL returns from the original send request 

Once a frame is received by Internet Mobility Protocol, the frame is 

15 quickly validated, then placed on an appropriate connection queue. If the 
frame does not contain enough informalion for Internet Mobility Protocol to 
discern its ultimate destination, fhe frame is placed on the Internet Mobility 
Protocol socket queue that the frame was received on, and then that socket 
queue is place on the global work queue for subsequence processing. This 

20 initial demultiplexing allows received work to be dispersed rapidly with 
limited processing overhead. 

Example Acquiescing 

To insure minimal use of network bandwidth during periods of 
retransmission and processing power on the Mobility Management Server 
25 102, the protocol allows the Mobility Management Server 102 to 

"acquiesce" a connection. After a user configurable period of time, the 
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MobiUty Management Server 102 wiU Stop retra^^ 
particular connection if it receives no notification from titie corresponding 
Mobile End System 104. At this point, the MobiUty Managemenit Server 
102 assumes that the Mobile End System 104 is in some unreachable state 
5 (i.e. out of range, suspended, etc), and places the connection into a dormant 
state. Any furUier yi^prk destined for Ms particul^^ for 
future delivery. The connection wiU rpnaain in tjbds state im 
following conditions are met: 

• Mobility Management Server 102 receives a frame from the 
10 Mobile End System 104i thus returning tiie connection to its 

■ ;^\;:0^giiial^starte^^ 

• a lifetime timeout has expired; 

: ' • an ihactivity timeout has expired; or 

• the connection is aborted by the system administrator. 
15 Mlti^ 

jframe from the Mobile End System 104, the connection continues from the 
point it was internipted. Aiiy work that was iqueued for the specific 
connection will be forwarded, and the state will be resynchronized. In any 
of the other cases, the Mobile End System 104 will be apprised of the 
20 ternlLiiation of the connection once it reconnects ; and work that was queued 
for the Mobile End System 104 win be discarded. 

Example Coiinect and Send Requests 

Figuies 1 OA- IOC together ai-e a flowchart of example connect and 
send request logic formed by Internet mobility engine 244. In response to 
25 receipt from a command from RPC engine 240, the Internet Mobility 
Protocol engine 244 determines whether the command is a "connect" 
request (decision block 602). If it is, engine 244 deterrnines whether 
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conneelion resources can be allocated (decision block 603). If it is not 
possible to allocate sufficient connection resources ("no" exit to decision 
block 603), engine 244 declares an error (block 603a) and returns. 
Otherwise, engine 244 performs a state configuration process in preparation 
5 for handling the connect request (block 603b); 

For connect and other requests* engine 244 qtieufes the connect or 
send request and signals a global event before return to the Calling 
application (block 604). 

To dispatch a connect or send request from tiie Internet Mobility 

10 Protocol global request queue, engine 244 first determiiies whether any 
work is pending (decision block 605). If no work iis pending ("no" exit to 
decision block 605), engine 244 waits for the application to queue work for 
the connection by going to Figure IOC, block 625 (block 605a). If there is 
work pending ("yes" exit to decision block 6Q5), engine 244 determines 

15 whether tiie current state has been estab^ 

establish has been achieyed ("yes" exit to decision block 606),. engine 244 
can skip steps used to transition into estabHsh state apd jump to decision 
block 615 of Figure lOB (block 606a). Otherwise^ engine 244 inust perform 
a sequence of steps to enter esta:blish state ("iiO- eTdt to decision block 606). 

20 In order to enter establish state* engine 244 first determines whether 

the address of its peer is knowja (decision block 607); If not,: engine 244 
waits for the peer address while continuing to queue work and tiransitions to 
Figure IOC block 625 (block 607a). If the peer address is known ("yes" exit 
to deciision block 607), engine 244 next tests whether the requisite security 

25 context has been acquired (decision block 608). If not, engiiie 244 must 
wait for the security context while continuing to qUeue work and 
transitioning to block 625 (block 608a). If seciurify context has already been 
acquired ("yes" exit to decision block 608), engihe 244 declares a "state 
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pending" state (block 608b), and then sends an Internet Mobility Protocol 
sync frame (block 609) and starts a retransniit tinaer (block 610). Engine 
244 determines whether the corresponding established frame was received 
(block 611). If it was not ("no" exitto decision block 611), engine 244 tests 
5 whether the retransmit time has expired (decision block 612). If the 

decision block has not expired ("no" ejdtto decision block 612), engine 244 
waits and may go to step; 625 (block 613). Eventually, if the established 
frame is never received (as tested for by block 611) and a total retransnmt 
titne expires (decision block 614), the connection may be aborted (block 

10 614a). If established is eventually received ("yes" exit to decision block 
611), engine 244 (feclares a "state estabHsh 

Once state establish has been achieved, engine 244 tests whether the 
new connection has been authenticated (decision block 615). If it has not 
been, engine 244 may wait and transition to step 625 (block 616). If the 

15 connection has been authenticated ("yes" exit to decision block 615), engine 
244 te^ts whether authentication succeeded (decision block 617). If it did 
not ("no" exit to decision block 617), the connection is aborted (block 
614a). Otherwise, engine 244 tests whether the peer transmit window is full 
(decision block 618). If it is ("yes" exit to decision block 618), engine 244 

20 waits for acknowledgment and goes to step 625 (deicision block 619). If the 
window is not fuU ("no" exit to decision block 618), engine 244 creates an 
Internet Mobility Protocol data frame (block 620) and sends it (block 621). 
Engine 244 then determines if the retransmit timer has started (decision 
block 622). If no, engine 244 starts the retransmit timer (block 623). 

25 Engine 244 loops through blocks 618-623 untii there is no more data to 
send (as tested for by decision block 624). Engine 244 then returns to a 
sleep mode waiting for more work and returns to the global dispatcher 
(block 625). 
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Example Termmation 

Figure 11 is a flowchart of example steps performed by Internet 
Mobility Protocol engine 244 to terminate a connection. In response to a 
"terminate connection" request (block 626), the engine queues the request to 
5 its global wbrk queue and returns to the caUiiig applieation (block 626a). 
The terminate request is eventually dispatched firom the Internet Mobility 
Protocol process global work queue for execution (block 627). Engine 244 
examines the terminate request and determines whether the terminate 
request should be immediate or graceful (decision block 628). If iniaiediate 

10 ("abort" exit to decision block 628); engine 244 iiniriediately aborts the 

connection (block 629). If graceful ("graceful" exit to decision block 628), 
engine 244 declares a "state close" state (block 628a), and sends an Internet 
Mobility Protocol "Mortis" frame (block 630) to indicate to the peer that the 
connection is to close. Engine 244 then declares a "Mortis" state (block 

15 630a) and starts the retransmit timer (block 631). Engine 244 tests whether 
the response of "post mortem" frame has been received from the peer 
(decision block 632). If not ("no" exit to decision block 632), engine 244 
detecrhines whether a retransmit timer has yet expired (decision block 633). 
If the retransmit timer is not expired ("no" exit to decision block 633), 

20 engine 244 waits and proceeds to step 637 (block 634). If die retransmit 
timer has expired ("yes" exit to decision block 633), engine 244 determines 
whether the total retransmit time has expired (deciision block 635). If the 
total time is not yet expired ("no" exit to decision block 635), control returns 
to block 630 to resent the Mortis ftaihe. If the total retfansnu^ 

25 expired ("yes" exit to decision block 635), engine 244 unmediately aborts 
the connection (block 635a). 

Once a "post mortem" responsive frame has been received from the 
peer ("yes" exit to decision block 632), engine 244 declares a "post mortem" 
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State (block 632a), releases connectionresources (block 636), and returns to 
sleep waiting for more work (block 637). 

Example Retransmission 

Figure 12 is ia flov^cliaurt of ex 
5 performed by Intemeit Mobility Protocol engine 244. In the event that the 
retransmit timer has expired (block 650), engine 244 determines whether 
any frames are putstariding (decision block 651). If no frames ate 
biitstandihg ("no" exit to decisioh block 651), eiigine 244 disinisses the 
tuner (block 652) arid returns to sleep (block 660). Ifv on the other hknd, 

10 frairies aire outstakding ("yes" exit to decision block 65 1), engine 244 

determines whether the entu e retransmit period has expired (deciisioh: block 
653). If it has riot ("no" exit to decision block 653), the pWciess i^etunls to 
sleep for the difference in time (block 654). If the entire retransnait time 
period lias expired ("yes" exit to decision block 653), engine 244 determines 

15 ■ whether a total retransmit period has expired (decision block 655). If it has 
("yes" exit to decision block 655) and this event has occurred in the 
Mobility Management Server engine 244' (as opposed to the Mobile End 
System engine 244), a dormant state is declared (decision block 656, block 
656a). Under these same conditions, the Internet Mobility Protocol engine 

20 244 executing on the Mobile End System 1 04 will abort the connection 
(block 656b). 

If the total retransmit period is not yet expired ("no" exit to decision 
block 655), engine 244 reprocesses the frame to remove any expired data 
(block 657) and then retransmits it (block 658) ~ restarting the retransmit 
25 timer as it does so (block 659). The process then returns to sleep (block 
660) to wait for the next event. 
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Example Internet Mobility Protocol expiration of a PDU 

Figure 12 block 657 allows for the requesting upper layer interface to 
specify a timeout or retry count for expiration of any protpool data unit (i.e. 
a SEND work request) submitted for transmission to the associated peser. By 
5 use of this functionality, Internet Mobility Protocol engine 244 maintains 
the semantics of unreliable data and provides other capabilities such as 
unreliable data i^emoval &om retrapsnutted fraiQ Each PDU (protocol 
data unit) 506 submitted by. the layer above can specify a validity timeout 
and'or retry count for each individual element that wUl evenmaUy be 

10 coalesced by the Internet MobUity Protocol engine 244. The validity 
vtimeout and/or retry coimt (which can be user-specified for some 
applications) are used to determine Which PDUs 506 should not be 
retransrnitted but should instead be removed from a firame prior to 
retransmission by engine 244. 

15 The vaUdity period associated with a PDU 506 specifies the relative 

tune period that the respective PDU should be considered for transmission. 
During submission, the Intemist MobUily Protocol RequestWork function 
checks the ejcpiry timeout value. If it is non-zero, an age timCT is irutialized. 
The requested data is then queued on the same queue as all other data being 

20 forwarded to the associated peer. If the given PDU 506 remains on the 
queue for longer than the time period specified by the validity peripd 
parsmieter, during the next event that the queue is, processed, the given (all) 
PDU(s) thjat has an expired timeout is removed and completed locally with a 
status code of "timeout failure" rather than being retransmitted when the 

25 frame is next retransmitted. This algorithm ensures that unrehable data 
being queued for transmission to the peer wiU not grow stale and/or 
boundlessly consimie system resources. 
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In the example shown in Figure 12Ai at least three separate PDUs 
506 are queued to Internet MobiUty Protocol engine 244 for subsequent 
prbce^^irig^ PDU 506(1) is queued wit^^ 

timeout for the given request. PDU 506(2) is specified with a validity 
5 period of 2 seconds and is chronologically queued after PDU 506(1). PDU 
506(n) is queued 2.5 seconds after PDU 506(2) was quieued. Sihce the act 
of queuing PErtiJ 506(n) is the fif ist event causing prbcessiiig of tiiie queue 
and PDU 506(2) expiry liine has lapsed, PDU 506(2) is remoVed frbm the 
work queue, completed locally and then PDU 5d6(n), is placed on the list. 
10 If a validity period was spiscified for PDU 506(ii) the previous sequence of 
events W6uld be lie^ 

manipulta the wodc (peue Mil cause ^tale PDUs to bfe r^moVbd aiid 
■■■cotnpleted.^ -^^''-'^-^' ; '-^ 

As described above, PDUs 506 are coalesced by the Internet 

15 Mobility Protocol Engine 244 transmit logic and formatted into a single data 
stream. EaciH discrete work element^ if not previously expired by the 
vaHdiiy timeout, is gathered to formulate Mteiiiet Mobility Protocol data 
frames. Internet Mobility Protocol Engine 244 ultimately sends these PDUs 
506 to the peer, and then plabes the associated frame on a Frames- 

20 Outstanding list. If the peer does not acknowledge the respective frame in a 
predetermined amount of time (see Figure 12 showing the retransmission 
algorithm), tiie frame is retransmitted to recover from pdssibly a lost or 
corrupted packet exchange. Jiist prior to retransmission, the PDU list that 
the frame is comprised of is iterated through to determine if any requests 

25 were queued with a retry count. If the retry coimt is non zero, and the valiie 
is decremented to zerOj. the PDU 506 is removed from the Mst, and the 
frames header is adjusted to denote the deletion of data. In this fashion, 
stale data, unreliable data, or applications employing their own 
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retrmsmission ppHcy a^^ 
algorithm. ; 

In the Figure 12B example, again three separate PDUs 506 are 
queued to Internet Mobility Protocol engine 244 for subsequent processing, 
5 PDU 506(1) is queued without a retry count. This denotes continuous 
retransnoissioii atten^ts py guaranteed deUvery level of service. PDU 
,506(2): j^s qu^eued with a retry count pf 1 and is chronplog^icaUy queued after 
PDU 506(1). PDU 506(n) is queued sometime after PDU 506(2). At this 
point, sonie external event (e.g., upper layer coalesce timer, etc.) causes 

10 engine 244's send Ipgip tp generate a new, fram PDUs 
506 prom the work queue to generate an Internet Mobility Protoepl data 
ftame 5pQ, "Hifs firaime'h and staraped wth ID 

pf 0 to denote that this is the first transmission of the frame. The frame is 
then h^ded to the NAL layer for subsequent tcansjnissipn to the network. 

15 At this point a retransmit timer is started sm.ce the frame in question 
contains a paylpad, For illustration purposes it is assumed that an 
acknowledgement is not received from the peer for a variety of possible 
reasons before the retransmit timer expires. The retransmit logic of engine 
244 determines that the frame 500 in question is now eligible for 

20 retransimssipn to the network. Prior to resubmitting the frame to the NAL 
layer, engine 244's Retransmit logic iterates through the associated list of 
PDUs 506, Each PDU' s. retry count is examined and if non-zerp, the count 
is decremented. In the process of decrementing PDU 506(2) 's retry count, 
the retry count becomes zero. Because PDU 506(2)' s retry count has gone 

25 to zero, it is rernoved frpm the list and completed locally with a status of 
"retry failure," The fram,e header 503 size is then adjusted to denote the 
absence pf the PDU 506(2) 's data. This process is repeated for all 
remaining PDUs. Once the entire frame 500 is reprocessed to produce an 
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"edited" frame 500', the retry ID in the header is incremented and the 
resultant datagram is then handed to the NAL layer for subsequent 

(re)traiismission. 

Example RcceDtion 

5 Figures 13A-13D are a flowchart of example steps performed by 

Internet Mobility Protocol engine 244 in response to receipt of a "receive" 
event. Such receive events are generated when an Internet Mobility 
Protocol frame has been received from network 108. In response to this 
receive event, engine 244 pre-validates the pvent (block 670) and tests 

10 whether it is a possible Internet Mobility Protocol frame (decision block 
671). If engine 244 determines that the received frame is not a possible 
frame ("no" exit to decision block 671), it discards the frame (block 672). 
Otherwise ("yes" exit to decision block 671), engine 244 determines 
whether there is a connection associated with the received frame (decision 

15 block 673). If there is a coimection associated with the received frame 
("yes" exit to decision block 673), engine 244 places the work on the 
connection receive queue (block 674), marks the connection as eligible to 
receive (block 675), and places the connection on the global work queue 
(block 676). If no connection has yet been associated with the received 

20 frame ("no" exit to decision block 673), engine 244 places the received 

frame on the socket receive queue (block 677) and places the socket receive 
. queue on the global work queue (block 678). In cither cas^e, engine 244 
signals a global work event (block 679). Upon dispatching of a "receive 
eligible" event from the global work queue (see Figure 13B), engine 244 de- 

25 queues the frame from the respective receive queue (block 680). It is 

possible that more then one IMP frame is received and queued before the 
Internet Mobility Protocol engine 244 can start de-queuing the messages , 
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Engine 244 loops until aU frames have been de-queue (blocks 681, 682). 
Once a frame has been de-queued ("yes" exit to decision block 681), engine 
244 validates the received frame (block 683) and determines whether it is 
okay (decision block 684). If the received frame is invalid, engine 244 
5 discards it (block 685) and de-queues the next frame from the receive queue 
(block 680). If the received frame is valid ("yes" exit to decision block 
684), engine 244 determines whether it is associated with aa existing 
connection (block 686). If it is not ("no" exit to decision block 686), engine 
244 tests whether it is a syac frame (decision block 687). If it is not a sync 

10 frame ("no" exit to decision block 687), the frame is discarded (block 685). 
If, on the other hand, a sync frame has been received ("yes" exit to decision 
block 687), engine 244 processes it using a passive connection request 
discussed in association with Figures 14A and 14B (block 688). 

If the frame is associated with a connection ("yes" exit to decision 

15 block 686), engine 244 determines whether the connection state is still 
active and not "post mortem" (decision block 689). If the connection is 
already "post mortem," the frame is discarded (block 685). Otherwise, 
engine 244 parses the frame (block 690) and determines whether it is an 
abort frame (decision block 691). If the frame is an abort frame, engine 244 

20 iomiediately aborts the connection (block 691a). If the frame is not an abort 
frame ("yes" exit to decision block 691), engine 244 processes 
acknowledgment information and releases any outstanding send frames 
(block 692). Engine 244 then posts the frame to any security subsystem for 
possible decryption (block 693). Once the frame is returned from the 

25 security subsystem engine 244 processes any control data (block 694). 
Engine 244 then determines whether the frame contains application data 
(decision block 695). If it does, this data is queued to the application layer 
(block 696). Engine 244 also determines whether the connection's state is 
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dormant (block 697 and 697a ~ iMs can happen on Mobility Management 
Server engine 244' ia the preferred embodiment), and returns state ba.ck to 



if the frame is possibly a "Mortis" frame ("yes" exit to decision block 
5 698), engine 244 indicates a "disconnect" to the application layer (block 
699) and enters the "Mortis" state (block 699a). It sends a "postmortem" 
fraiiie! tp the peer (block 700), and enters the "post mbrtem" state (block 
7G0a). Engine 244 then releases connection resources (block 701) and 
returns to sleep waiting for more work (block 702). If the parsed frame is a 
10 "post mortem" frame ("yes" exit to decision block 703), blocks 700a, 701, 
702 are executed. Olherwise, control returns to block 680 to dequeue the 
next frame from the receive queue (block 704). 

Example Passive Connectinns 

Blocks 14A-14B are together a flowchart of example steps 
15 peif ormed by Internet Mobility Protocol engine 244 in response to a 

"passive coimection" request. Engine 244 first determines whether there is 
another connection for this particular device, (block 720). If there is ("yes" 
exit to decision block 720), the engine determines whether it is the initial 
connection (decision block 721). If peer believes the new connection is the 
20 initial connection ("yes" exit to decision block 721), engine 244 aborts the 
previous connections (block 722). If not the initial connection ("no" exit to 
decision block 721), engine 244 tests whether tiie sequence and connection 
ID match (decision block 723). If they do not match ("no" exit to decision 
block 723), control returns to decision block 720. If the sequence and 
25 connection ID do match ("yes" exit to decision block 723), engine 244 

discards duplicate frames (block 724) and returns to step 680 of Figure 13B 
(block 725). 
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engine 244 deteniiio.es whether it ean allpeate connectiGn resources for the 
connectiori (decision block 726). If it cannot, an error is declared ("no" exit 
_ to decision block 726, block 727), and the connection is aborted (block 
5 728). K it is possible to allocate connection resources ("yes" exit to 

decision block 726), engiae 244 declares a "ebnfigiire" state (block 726a) 
and acquires the security context for the coimectioh (block 730). If it was 
not possible to acquire sufficient security context ("no" exit to decision 
block 731), the connection is aborted (block 728). Otherwise, engine 244 

10 sends ah established frame (block 732) and declares the eonneQtion to be in 
state "establish" (block 732a). Engine 244 then startis a retramsinittiBfc (block 
733) and waits for the authentication process to cOttclude (blQek;734). 
Eventually, engine 244 tests whether the device and user have both been 
authenticated (block 735). If either the device or the user is not 

15 authenticated, the connection is aborted (block 736). Otlierwjse, engine 244 
indicates the cbraiection t6 the liistenihg aijipiicatibh (bldck 737) and gets the 
configuration (block 738). If either of these steps do hot succeed, the 
connection is aborted (decision block 739, block 740). Otherwise, the 
process returns to sleep waiting for more work (block 741), ' 

20 Example Abnormal Termmation 

Figures 15A and 15B are a. flowchart of example steps performed by 
tlie lnternet Mobili^ Protocol engine 244 in responsfe to an "abort" 
connection request. Upon receipt of such a request froin another process 
(block 999) and dispatched via the queue (block 1000), engine 244 

25 deternGttnes whether a connection is associated with the request (decision 
block lOOi). If it is ("yes!' exit to decision block 1001), engine 244 saves 
the original state (block 1002) and declares an "abort" state (block 10()2a). 
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Engine 244 then determines whether the connection was indicated to the 
RPC engine (decision block 1003) ~ and if so, indicates a disconnect 
event(block 1004). Engine 244 tihien declares a "post mortem" state (block 
1003a)i ireleases the resotirces previously allocated to the particular 
5 connection (block 1005), and tests whether the original state is greater than 
the state pending (decision block 1006). If not ("no" exit to decision block 
1006), the process traiisitions to block 1012 to return to the eaUing routine 
(block 1007). Otherwise, engine 244 detennines whether the request is 
associated with a received frame (decision block 1008). If the abort request 
10 is associated with a received frame, and the received frame is an abort frame 
(decision block 1009), the received frame is discarded (block 1010). 
Otherwise engine 244 wiU send an abort fraine (block 101 1) before 
returning to the calling routine (block 1012). , 

Example B oaminyy rnntrnl 

15 Referring once again to Figure 1, mobile network 108 may comprise 

a number of different segments providing different network interconnects 
(107a- 107k corresponding to different wireless transceivers 106a- 106k). In 
accordance with another aspect of the present invention, network 108 
including Mobility Management Server 102 is able to gracefully handle a 

20 "roaming" condition in which a Mobile End System 104 has moved from 
one network interconnect to another. Commonly, network 108 topographies 
are divided into segments (subnets) for management and other purposes. 
These different segments typically assijgn different network (transport) 
iaddresses to the various Mobile End Systems 104 within the given segment. 

25 It is common to use a Dynamic Host Configuration R-otocol (DHCP) 

to automatically configure network. devices that are newly activated on such 
a subnet. For example, a DHCP server on the sub-net typically provides its 
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clients with (among other things) a valid network address to "lease". DHCP 
clients may not have permanently assigned, "hard coded" network 
addresses. Instead, at boot time, the DHCP client requests a network 
address firom the DHCP server. The DHCP server has a pool of network 
5 addresses that are available for assigmnent. When a DHCP client requests 
an network address, the DHCP server assigns, or leases, an available 
address from that pool to the client The assigned network address is then 
owned" by the client for a specified period ("lease dm-ation"). When the 
lease expires, the network address is returned to the pool and becomes 
10 available for reassignment to another eUent. In addition to automatically 
assigning network addresses, DHCP also provides netmasks and other 
configuration information to clients running DHCP client software. More 
information concerning the standard DHCP protocol Can be found in 
RFC2131, 

15 Thus, when a Mobile End System 104 using DHCP roarns from one 

subnet to another, it will appear wi& a new network address. In accordance 
with one aspect of the present invention. Mobile End Systems 104 and 
Mobility Management Server 102 take advantage of the automatic 
configuration functionality of DHCP, and coordinate together to ensure that 

20 the Mobility Management Server recognizes ttie Mobile End System's 
"new" network address and associates it with the previously-established 
cbilnectioh the Mobility Mahagemerit Server is proxying on its behalf ^ 
One example embodiment uses standard DHCP Discover/Offer 
client-server broadcast messaging sequences as mi echo request-response, 

25 along with 0|ther standard na^fhodoiogies in order to determine if a Mobile 
End SysteijQi04 has foamed to a new subnet or is out of range. In 
accordance with the standard DHCP protocol, a Mobile End System 104 
requiring a network address will periodically broadcast client identifier and 
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hardware address as part of a DHGP Discover message. The DHCP server 
will broadcast its Off er response (this message is broadcast rather than 
transmitted specifically to the requesting Mobile End System because the 
Mobile End System doesn't yet have a network address to send to). Thus, 
5 any Mobile End System 104 on the particular subnet will pick up any DHCP 
Offer server response to any other Mobile End System broadcast on the 
,■ same subnet. 

This example embodiment provides DHCP listeners to monitor tlie 
DHCP broadcast messages and thereby ascertain whether a particular 
10 Mobile End System 104 has; rpatned j&rom one subnet to another and is being 
off ered tjb^e abihiy to apqi^ a new network address by DHCP. Figure 16 
shows example PHCP listener data structures. For exjtcnple, a Mobile End 
System listener data structure 902 may comprise: 

• a. linked list of server data structures, 
15 J • an integer transaction It) number (xid), 

• a counter ("ping"), and 

• a timeout value. 

A server data structure 904 may comprise a linked hst of data blocks each 
defining a different DHCP server, each data block comprising: 
20 • a pointer to next server, 

• a server ID (network address of a DHCP server), 

• an address (giaddr) of a BOOTP relay agent recently associated 
with this DHCP server, 

• a "ping" value (socket -> ping), and 
25 • a flag. 
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These data Structures are continuaUy updated 
broadcast traffic appearing on network 108. The following example 
functions can be used to maintain these data structures: 

• roamCreateO [initialize variables] 

5 • roaraDeinitializeO [delete all listeners] 

• rbamStartlndicationsO [caU a suppUed caUback routine when a 
Mobile End System has roamed or changed interfa:ces, to give a 
registrant roaming indications] 

• roamStopIndicationsO [remove the aJ)propriate callback from the 
10 Hst/to stop giyittg a registrant roaininjg indicati^ 

• Interface Change [cailbabk notification from oipferating syste 
indicatidg an interface has changed its network addfiess] 

• Ostener Signal [per-iriterf ace callback from a Listener indicating 
a roaming or out-of-range or back-in-range eohdition] . 

1 5 Additionally, a refresh process toay be used to update Listeners after 

interface changes. 

In the preferred embodiment, all Mobile End Systems 104 transmit 
the salne Ghent Identifier and Hardware Address in DHGP Discover 
requests. This allows the listener data structures and associated processes to 

20 distinguish Mobile End System-originated Discover requests from Discover 
requests initiated by other network devices. Likewise, the DHCP server 
will broadcast its response, so any Mobile End System 1 04 and/or the 
Mobility Management Server 102 wiU bo able to pick up the DHCP server 
Offer response to any other Mobile End System. Since multiple DHCP 

25 servers can respond to a single DHCP Discover message, the listener data 
structures shown in Figure 16 store each server response in a separate data 
block, tied to the main handle via linked list. 
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Upon reeeiving a Discover request having the predetermined Client 
Hardware Address and Ghent Identifier, l3ie prefer^ 
reeognizes this request as cdniing from a Mobile End System If the 
message also has a BQOTP reilay address set to zero, this indicates that the 
5 message Giigihated on the same subnet as the Hstener. Listeners may ignore 
aU DHCP Offers unless they have a: transaction ID (xid) matching that of a 
Discover message recently sent by a Mobile End System 104. The listener 
dan detenpine that a Mobile En^ roamed if any response 

comes from a known server with a new BOOT? relay agent ID and/or 
10 offered network address masked with an offered subnet mask. Listeners 
add hew servers to the Fij^ 

positive response frotn an old server. If a listener receives responses from 

new server(s) but none from an old seryer, this may kidicate roaniing (tW 

cmbe a configurable option). If the listener fails to receive responses from 
15 jiew or old servers, the listener is out of range (this determination can be 

used to ?ignal^ upper 1^^ 

sen<jUmg of dzita to a^ 

If the listener never receives a response from any server, there is no 

point of reference and thus impossible to determine whether roatning has 
20 occurred. This condition can be handled by signaling an exiror after a 

timeout and aUowing the caUer to retr^f d^^^ 

embodiment determines that a Mobile End System 104 has roamed if any 
response has come from a loiown server with a new BOOTP relay agent ID 
(or a new offered network address when masked with offered subnet mask). 
25 If the listener data structqres see responses from new servers but none from 
an old server, it is posisi^ble that roaming has occurred, but there nlust be a 
delay before signaling, hi order to wait for any potential responses from the 
old servers. If there are no responses frona new or old servers, then the 
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Mobile End System 104 is probably out of range and Mobility Management 
Server 102 waits for it to coome back into rang^^ 

Figure 17 is a flowchart of example steps of a Listener process of tlie 
preferred embodiment. Referring to Figure 17, a DHGP listener process is 
5 created by allbcating appropriate men^^ 

sockets for the D^CP cUbnt and server UDP ports; and setting t^ceive 
Callbacks for botb. A timer is then set (^loek 802^ 
enters die "Wait" state. to wait for a roaming related event (block 804). 
Three external inputs can trigger an events 
10 • a DHCP server packet is received; 

• a DHCP client packet sent by another Mobile End System is 
:'. 'rec:^ed->'^- 

• ' a tirner'tbitedut-oeGiMS: 

If a DHCP server packet has been.received, the packet is examined 
15 to deterBbane whether its client identifiejF nialches the predetbimained client 
ID (decision bldck 806). If it does not, it is discarded. However, if the 
packet does contain the predetermined ID, a test is performed to determine 
whether the packet is a DHCP Offer packet (diemion block^ 
packets are rejected unleiss they cofltaih a trtosaction E) initchinjg si r^ 
20 sent DHCP Discover sequence. 

If the packet transaction ID matches (block 810), then a test is made 
SLS to whether the server seiadiUg the DHCP offer packet is Imown (i.e., the 
server ID is in the Ustener data structure shown in FiglJa- 
If the server ID is not on the list ("iio." exit to decision block 812), it is 
25 added tb the list iahd marked as "riew" (or "first" if it is the Mst servei: on the 
list) (block 822). If the server is already on the list ("Y" exit to decision 
block 8 12), a further test is peirfoimed to determine whether the packet 
BOOTT relay address ("GIADDR") matches the server address 
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("GIADDR") (decision block 814). If there is no match, then the Offer 
packet must be originating from a different subnetj and it is determined that 
a "hard roam" has occurred (block 816). The caller application is signaled 
that there has been a roam. If, on the other hand, decision block 814 
5 determines there is a match in BOOTP relay addresses, then no roam has 
oecuiredj the listener process stamps the server receive time, resets "new" 
flags for aU other servers on the Ust, and stores the current ping number 
with the server (block 818, 820). The process then returns to "wait" period. 
If liie event is a received client packet, the listener process 

10 deteraiines whether tlie packet has the predetermined client ED, is a DHCP 
Discover packet and has a BOOTP relay address (GIADDR) of 0 (blocks 
824, 826, 828). These steps determine whethe:^ the received packet is 
DHCP Discover message sent by another Mobile Bid System 104 on the 
same sub-net as the listener; If so, the listener process then sets the 

15 transaction ED to the peer's transaction ID (block 830) for use in comparing 
with later-received DHCP Offer packets, calls a ping check (block 834) and 
resets the timer (block 836). 

In response to a timer timeout;/the process calls a "ping check" 
(block 838). "Pings" in the preferred embodiment are DHCP Discover 

20 packets with a random new xid. Example steps for this ping check 838 are 
shown in Figure 17A. The purpose of the ping check routine is to 
destemaine if a "soft roanii" condition has occurred (i.e., a Mobile End 
. System has temporarily lost and then regained contact Wifli a sub-net, but 
has not roamed to a different sub-net). The process determines whether 

25 there is a sub-net roam condition, an out-of-raiige cdndition, or a "no 
server" condition. In other Words: 

• Has a Mobile End System roamed from one sub-net to another? 

• Is a Mobile End System out of range? 
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• Is a DHCP server absent? . 
These conditions are determined by coniparing Mobile End Systein prior 
"piag" response with the current "ping" response (decision blocks 846, 
850). For example, if the current ping nmnber minus the old server's last 
5 ping response is greater fhain the sub^net server phigis and there is at least 
one server marked "new," there has been a snb-i^et roam to a different 
server. T3ie result b^^ logic is to either signal a subset roam, and out of 
range condition or a no server condition (or none of thes^ 
process. ... ../.v-^^-, ' ■ 

10 Figure 1 8 shows a flowchart of example steps performed by a 

Mobile Eiid System 104 roaming control center. To enable roaming at the 
Mobile End Systerh 104, the list of known addresses is initialized to zero 
(block 850) and an operating system interface change notification is enabled 
(block 852). The process then calls the operating system to get a hst of 

15 current addresses that use DHCP (block 854). All known addresses no 
longer .in the current list haye their corresponding listeners closed (block 
856). Similarly, the process opens listeners on all current but not known 
interfaces (block 858). The process then signials "roam" to registrants 
(block 860). 

20 When the Hstener process of Figure 17 signals (block 862), the 

process determines whether the signal indicates a "roam", "out of range" or 
"back in range" condition (decision block 864, 870, 874). A roam signal 
("yes" exit to decision block 864) causes the process to close corresponding 
hstener 866 and call the operating.system to release and renew DHCP lease 

25 to a network address (block 868). If the listener signals "out of range" 

(decision block 870), the process signals this condition to registrants (block 
872). If the signal is a "back in range" (decision block 874), then this 
condition is signaled to aU registrants (block 876). Upon receiving a 
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disabled roam command (block 878), the process closes all listeners (block 
880) and disables the operating system interface change notification (block 
882). 

Example Interface Assisted Unaminyi; Listener 
5 A further, interface-based listener feature enables roaming across 

network points of attachment on the same network or across different 
network media. This interface-based Ustener feature, operates without 
requiring the beaconing techniques described above, while permittihg the 
system to fall back on beaconing if the underlying interface(s) is unable to 

10 support the appropriate signaling. 

In tbis further embodiment, an interface-based listener integrates 
information from network interface adapters (e.g., via a low level interface 
roaming driver) with information available from network stacks to 
determine whether a mobile node has moved to a new Network Point of 

15 Attachment. Figures 19A & 19B show an example Ustener algorithm that 
may be used to efficiently determine the migration path of the mobile node. 
This process is shown using a single network interface connected to a single 
network medium, but can be used by itself or in conjunction with other 
roaming algorithms to traverse across many diverse network media and 

20 interfaces (e.g., to create a self-healing infrastructure using redundant 
paths). 

Referring to Figure 19 A, at system initialization time or when the 
network adapter driver loads (Figure 19A, block 2000), low-lpvel interface 
roaming drivers register with the roaming control center module of Figure 
25 18 (block 2010). Such registration (which is made via the function 

crRegisterCardiHandlerO in the example embodiment) provides entcy points 
for: 
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'^open, ■■■■ 

• close, 

• get status, and 

• a Boolean set to TRUOE if the driver can notify the registrant of 
5 changes in status, and FALSE if the roaming control center 

module should use timer-based (or other) polling to check status. 
The example embocMment function crRegisterGardHandlerO also 
provides a interface description string or token that can be used by the 
roaming control center module for preliminary matct-ups to the correct 
10 roaming driver. A default roaming driver may also be installed for 
interfaces that use an O/S generic mechanisin for sigm^ 
connectivity as well as changes to network poult of attachments. 

In the example embodiment, when an interface's state becomes 
enabled (i.e. access to the network is now possible) (block 2020), the 
15 roaming control center tries to enable Interface Assisted lEloaniing (lAR) 

according to the following steps (please note however, that the steps may be 
interchanged or either might be omitted based on the design of the operating 
system (O/S) and/or the hpsting device tseing used in a particular 
application): 

20 1 . If a generic handler is installed, a call to the generic 

crOpenlnstanceG handler is made. The generic handler queries the low- 
level adapter driver to see if it can generically support signaling the status of 
media connectivity as well as any changes to the network point of 
attachment (block 2030). If the interface driver is unable to support this 

25 functionality generically ("no" exit to block 2030), an error status is 

returned to the caller to indicate that it should use an alternative mechanism 
for acquiring signaling information. 
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2. If the generic handler returns an error ("no" exit to block 2030), a 
search is made with the token of the activated interface through the 
currently registered roaming drivers (block 2G40). If the interface matches 
one of the tokens that was registered during erRegisterCardHandlerQ phase 

5 (block 2050), the roamiag contiol center calls the specific crOpenlnstanceO 
for that instance of the adapter. This function attempts to open the low level 
driver, poll once for status (media connectivity, and the network point of 
attachmisnt ID), and set the periodic polling timer (if applicable). If the low- 
level driver does not support the requests for some reason, an error is 
10 returned indicating that the roarning control center should use an alternate 
mechanism for acquirmg sigrialing information.. 

3 . If either of the previous steps is unable to achieve the required 
funetionalityi an error is returned to the roaming control center to signal that 
it should not use the lAR functionality and fall back to other ix)an3ing 

15 algorithms, such as the beaconing listener shown in Figure 17 & 17Aj 

MobUe IP, or in some cases the currentiy attached network itself deals with 
roaniing ("no" exit to block 2050, block 2999). Otherwise Interface Assisted 
Roaming is enabled (block 2060) and the roaming control center follows the 
algorithm outlined below. 

20 Initially, the interface-assisted Mstener records current media 

connectivity status and network point of attachment identification 
irrformation in a local data store (block 2060). Assuming the interface 
assisted subsystem is successful in providing roaming feedback, the 
subsystem waits for a status event (block 2100). The event can comprise, 

25 for example: 

• a callback from tihe low level roaming driver, 

• atimedpollinterval(blocks2070, 2090), or 
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• a hint from network level actiAdiy (i.e. trouble 

transmitting/receiving) (block 2080). 
If the status of the interface signifies either a change in medium 
connectivity has occurred, or a change in network point of attachment 
5 ("yes" exit to block 2110 or 2120 of Figure 19B), any clients bf the roaming 
control center are notified of the state change using tbe following rules: 

1 . If the status signifies a change from being connected to the 
underlying network medium to being detached ("yes" exit to block 2120) 
and there are no other paths to the peer, the listener concludes that the 

10 mobile end system has lost its connection, and the roaming control center 
signals its clients with a status of ROAM_SICtNAL_OUT_OF^GO]SITACT 
(block 2140). 

2. If the status signifies that the interface has been reconnected to the 
medium, and. the network point of attachment has not changed ("no" exit to 

15 block 2150 after "no" exit to block 2120) and a 

RPAM_SIGNAL_OUT_OF^CONTACT was previously signaled, this 
indicates that the mobile end system had previously lost but has now 
reestablished contact with a particular network point of attachment. In tliis 
case, the roaming control center will revalidate any network address it may 

20 have registered or acquired for proper access (block 2170), and signals 
ROAM_SIGNALJlOAM_SAME_SUBNET (block 2180) to alert the 
roaming control center clients that a reattachment has occurred and that they 
should take whatever steps necessary to quickly reestablish transport level 
communications. For example, during Ihe disruption in service it is possible 

25 that some data may have been lost — and the chents may need to act to 
recover such lost data. 

3. if the status signifies that the interface is attached to the medium 
but the network point of attachment has changed ("yes" exit to block 2150), 
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the rpaming control center will signal its clients that a roaming condition 
has occurred. To miore efficiently support handoffs between network point 
of attachinentSj the roaming control center in this example employs the use 
of a learning algorithnqi along with a local data-s^^ 
5 normally populated dynamically (i.e. learning), but it can be seeded with 
static information (i.e., already learned information) to improve 
performance. The data-store itself maintains a list of network points of 
attachment identifiers, along with informatidn such as network and media 
access address, network mask, etc. This "network topology map" assists the 
10 roaming control cehter in deciding the correct signal to generate to its 
clients. . 

Determination of the correct signal is done in the following manner 
in the example embodirnent: 

a) A search is made through the network topology map data-store to 
15 determine if the interface has abready visited this particular network point of 
attaclment (block 2190). Jf a match is found ("yes" exit to block 2200), a 
further check is inade to see if the network point of attachment is on (he 
sarhe network segment as tiie one that the interface was previously 
. associated with. If the network segment is the same, the roaming control 
20 center generates a ROAM_SIGNAL_ROAM_SAME_SUBNET. This alerts 
the roaming control center clients that a handoff occurred and it should take 
whatever steps necessary to quickly reestablish transport level 
communications as during the handoff it is possible that some data may 
have been lost. 

25 b) If during the search a match is found, but the new network point 

of attachment is not on the same network segment, then the listener 
concludes that the mobile end system has roamed to a different subnetwork. 
In this case, the roaming control center: 
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• acqiakes an address that is usatle on the aew^^i^^ 
(bloefc 2220). This may entaH registering the Gira^ 

valid on the new segment, (re)acquuing an address from a local 
server, having one statically defined, or using heuristics to 
5 determine that an address that was previdusly assigned is still 

valid; In the latter case^ the roaming control center may determine 
that the interface is changing between a given set of network 
point of attachments and may not immediately relinquish or de- 
register the network address for performance reasons. In this 

10 example, there is a difference between acquiding^^ to 

the network (e.g., via DHCP) or registering the address on the 
local network (e.g., via a foreign agent in Mobile The 
roaming entity either (re)acquires (e.g., possibly 
establishing/updating a lease with the DHCP server) or registers 

15 the current address with a foreign agent (Mobile BP). ; 

• Generates a ROAM_SIGNAL_ROAM signal to its cliehts (block 
2230) indicating roanoing to a different subnet. 

e) If the search yields no match ("no" exit to block 2200), a new 
record is created in the local data-store populated with the network point of 

20 attachment's identifier, media access aiddress, network mask ^ 

ancillary information (block 2210). The roaming control center then 
executes blocks 2220 and 2230 to acquire and register a network addf ess, 
and to generate a "roam" signal. 

Since the interface-assisted roaming technique described above gives 

25 access to the underlying interface inf ormatioUi it is possible to employ an 
additional set of policy p^ameters (defined by the user £flid/dr the system) 
that can enable automatic efficient siBlectidn of alternate valid network 
paths. If there is more than one network available iat a time, the subsystem 



WO02/23362 



85 



PCT/USO 1/28391 



can choose the path(s) with the least cost associated with it (i.e., a wide area 
netwprk corniectioii versus a local iai-ea connectioii); This can be done by a 
number of nietrics such as, for exaniple. b 
5? quglity of serviee. - Such "least cost routing" techniques cart provide 
•5 advantages in terms of network connection quahty, efficiency, and 
reduction in frame loss; For example, it is possible to provide a "inalce 
before break'' handoff scheihe based on other heuristics available (media 
connectivity, signal strength, retransmission rate, etc), thus allowing 
eontinuous packet flow with rniniinal loss to and from the roaming node. 
10 See policy management discussion below, r 

Figure 20 shows an example interface assisted roai^ 
node data structure. Figure 20 shows this data structure inaplemented as a 
linked list, but it could alternatively be represented as an array where the 

15 next and previous fields are omitted. In a wireless network infrastructure 
the "NPOA" may, for example, be the MAC address of the access point or 
base station that the mobile node is associated with. In other networks, it 
; rnay be the unique identifier of an intervening network interconnect (e.g., 
gateway,. IWF, etc.). The data structure may be seeded with static 

20 information or dynamically learned. Other information may also be 

associated with each node (e.g., MTU size, latency, cost, availabUlty, etc.) 

■ - EXAMPLE FURTIJJER EMBQDIMllNT TO HAM)LE CERTAIN 
RAGE CONDITIONS 

Through further experimentation evidence has shown, that some 
25 network adapters may erroneously signal that they are (re)connedted to the 
medium before they are totally registered on the network segment. In some 
instances dtttihg roaming events the storage area of where the network 
identifier is kept may not yet been updated, and thus it is possible fdr the 
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sysfem to incorrectly believe that these adapters have roamed back onto the 
same subnet. EventuaUy, when the device fimshes registerin 
area is updated with the new network identifier, causing yet another ROAM 
signal to be generated. This scenario would correctly work if both pieces of 
5 information were gated together and only signaled once when the interface 
was finished registering with the network. However when poUtng i 
difficult to deterinine when the network ID is; vaU 
network" signal is generated previously. 

In essences the roatning node may in fact be in media connectivity 

.10 state since it can communiciate at themedia acieess level with the iietwork, 
but in fact one catmot yet send any application data across the link since the 
registration process has not completed. Thereforei it is^^^^^ 
compensate for this condition. One way to provide such compensation is to 
determine peer connectivity by sending link confhmation frames, or what is . 

15 more commonly known as an echo request/response packets. These echo or 
ping frames are generated by one peer (most likely the roaming node)i to 
deteiniine if two-way peer-^to-^peer connectivity is achievable. If the 
requesting peer receives a response frame to its request, it can be concluded 
that a duplex path has been achieved. At this point, the NPOA information 

20 can be regarded as valid until the next disconnect situation is reahzed. Other 
information, such as the reception of any frame j&rom the peer on the 
interface in question, also allows tiie roaming node to assume the 
registration process has concluded and tworway cornmunications is 
achievable. 

25 Another race condition between the network interface and the 

underlying protocol stack situation has arisen that can sometimes caijse a 
problem. It is possible for a device to have roamed to a new network 
segment and been signaled correcfly from the interface below, but the 
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transport stack itself has not made the necessary adjustments to its routing 
table(s) for application data to flow. To compensate for this condition, an 
additional signal ROAM_SIGNAL_ROUTE_CHANGE, was added and is 
generated whenever the underlying transport's routing table changes. When 
5 lliis signal is indicated, the roaming subsystem clients take whatever action 
is necessary to determine if connectivity to the peer systems is achievable. 
IMs may entail the roaming client to enumerate through the underlying 
traasport's routing table to determine if the routing modification^ 
affected the communications path to the peer. Other more intrusive 
10 algorithms, such as the ones described above, can also be used to confinn 
that a two-way communication path exists between the peers. 

ExamBle Roaming Across Disiomt Networks 

A fralher aspect of an example nonrlimiting preferred embodiment 
of our invention provides an algoiitihm and arrangement for accessing the 

15 MMS (Mobility Management Server) in what we call "disjoint networking" 
mode. The new algoriHim allows for dynamic/static discovery of alternate 
network addresses that can be used to establish/continue communications 
with an MMS ~ even in a disjoint network topology in which one network 
may have no knowledge of network addresses for another network. 

20 In general, the algorithm aUows for a hst of alternate addresses tliat 

the MMS is available at to be forwarded to an MES (Mobile End System) 
during the course of a conversation. Thus, the MMS uses a connection over 
one network to send the MES one or more MMS network addresses or othet 
MMS ideiitities corresponding to other networks. As one example, this hst 

25 can sent during circuit creation. It is also possible for the list to change 
midstream. In this case, the hst can be updated at any time during the 
connection. 
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If/when the MES roams to another network^ it uses the list of MMS 
"alias" addresses/identifications to contact the MMS from the new network 
point of attachment. This allows tlie MES to re-establish contact with die 
MMS over the new network connection even though the primary and 
5 ancillary networks may n9t share any address or other information. 

Figure 21 shows a simplified flowchart of this new technique. 
Suppose that the. MMS 102 is connected to two different disjoint networks 
or network segments Nl and N2. Suppose that the MES 104 is initially 
coupled to the MES 102 via network Nl. Once a connection has been 

10 established between the MES 104 and the MMS 102 over network Nl , the 
MMS 102 can send the MES 104 a list L of network addresses or other 
identifiers that the MMS is caUed on one or more other networks (e.g., 
network N2). The MES 104 receives and stores this hst L. Then, when the 
MES 104 roams to another network (N2), it can access this stored Ust L and 

15 use it to efficiently re-establish communication with the MMS 102 over the 
new network (N2). 

There are at least several uses for this new algorithm in addition to 
the ability to more efficiently obtain an alternative network address or other 
identifier for communicating with the MMS 102 over a disjoint network. 

20 One example usage is secure network operation. For example, using the 
algorithm shown m Figure 21, one can. setup a secure network where.ihe 
MMS 102 is used as a secure firewall/gateway from a multitude of networks 
(some/all may be wireless) and a corporate backbone, and allow for secure 
and seamless migration of the mobile node 104 between all disassociated 

25 networks. Think, for example, of the MMS 102 as a hub, with one fat pipe 
connecting to the corporate network and many little spokes connecting 
many logically discrete networks. Since they are logically discriete, traffic 
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on one network segment cannotreaeli another, except through the MMS 
102 (which can act as a router in thLs example). 

Nordaaily for a node to roam from network segment to network 
segment, there must be routmg information/paths provided on each network 
5 segment (i.e. default route, etc) specifying how to get back to the "main 
public or Mtial address'V used to contact the^^ M^ a comiection 

is estabJished, that address iis used for^^l^^ of the conneGtiojiv When a 
•frame is sent from the MES 104, the IP network (layer 3) infrastructure on 
the client and intermediary nodes (routers) looks at the destiaation address 

10 of the frame and correctly forwards the packet oh to its ultimate destination 
(the MMS 102). This is done by using what is commonly referred to as IP 
forwarding, or iP routiiig. With this fimctionality turned on, frames 
(broadcasts, etc) frorn one network segment can leak onto another. By not 
using IP forwardingi frames sent on one segment are not forwarded onto the 

15 other, thus brealdng the communicatidns pipe or creating a disjdiiit iietwbrk. 
The altemdB address list shown imFigurg 21 has the effect of 
pushing or distributing some of the routing intelligence ont to the MEiS 104. 
Each segment therefore can be kept discrete and without knowledge of any 
Other segment attached to the MMS 102. The MES 104 can be 

20 authenticated by the MMS 102 so that the MMS only sends a list L to 
authorized MES units 104. When the MES 104 roams onto another 
; networks segmentj it can automatically select the correct address to use to 
initiate/continue communications with the MMS midstream, thus solving 
the disjoint network problem, and not require any changes to the routing 

25 infrastructure. This provides for a more secure corbputing environment by 
only letting validated users to gain access to the network/ 

For example, by using the MMS 102 in this manner corabined with 
user level security/encryption, we can limit traffic from and to the corporate 
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backbone to only the frames destined foi those nodes on that segment using 
the roaming techniques described above. Frames can be optionally 
encrypted to thwart any potential eavesdropping by devices that may be 
validated by the spoke network infrastracture. 
5 Figinre 22 shows an example. I^^^ 

to four separate and distinct networks (la, lb, Ic, Id) \yithout any 
interconnects or route information shared^ For all intents and piiiposeSi, each 
network I is an island. Now envision an MES 104 being docked to one of 
the networks (e.g., Ic) using a wired connection on the corporate backbone. 

10 For example^ suppose that tlie R<pS: 104 apqt^ 

192.168.X.X network to communicate with the MMS 102. 

Now suppose that for some reason, the MES now needs to migrate or 
roam to the lO.l.x.x (la) network. Since the lO.l.x.x (la) network has no 
knowledgeof the 192.168.X.X (lb) network (i.e. no roti^^^ 

15 MEIS il04nioves into itsdoinaini the communicalion pipe is broken 

tihough the MMS is attached to it. Agahii the same thing happens when the 
mobile node 104 attaches to any of the other 10.x networks depicted. 

Now using the algorithm shown in Figure 21, the MMS 102 at 
connection initiation time (or by some Other method) shares its interfaces 

20 address on each of the yaribus disjoint networks la, Ib^ Ic, Id mth the MES 
104 and the MES records these. Once recorded; if the MES 104: roams iiito 
any one of the networks and detects that it has roamed onto a new network 
segment, the MES can now select the appropriate network address to. 
communicate wilfe the MMS for that network segment; If more then one 

25 - address can be used, the MES 104 can select the appropriate address to use 
based on a number of metrics such as speed, cost, availability, hops, etc. An 
MES 104 that has not received a Kst as in Figure 21 may be effectively 
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prevented, firom rotoding between the various networks because it has no 
way to contact the MMS over any network other than its "home" network. 

Another ajppHcation for the Figure 2 r technique is in distributed 
-network interfaces . In today's networks, folks have deployed what is known 
5 as NetWork Address Translators (NATs): By use of this eonventidnal 
technology, one can have many network devices use only otie public 
network address for access to information on the Internet. The technology 
provides this functionality by funncling all information and queries destined 
to the Internet tlirough a single/few device(s). The device(s) records the 

10 request at the network layer, then remaps the address and port information 
in the packet to the devices own address/port tuple and sends it onto its 
destination. Upon reception of a frame from the Internet or other such 
network, the device(s) does the reverse look and forwards it back to the 
correct source by replacing its address/port tuple information with that of 

15 the initiating device. These mappings may be defined statically also at the 
NAT. ' • , 

Suppose someone wants to use the MMS 102 for the LANAVLAN 
internally and have it sit behind a NAT. Cun-ently, unless the MMS 102 is 
the NAT, or by using a different proxy for all communications with the 

20 MMS, when someone roams outside of the bounds of the iutranet, the MMS 
is no longer accessible since the address to converse with it is no longer 
accessible. With the Figure 21 algorithm, one can statically/dynamically 
define another interface address that is not directly attached to the MMS. 
Therefore, using the algorithm described above, Ibe MES 104 can now 

25 automatically select the appropriate disjoint address to use when attaching 
to a network that is outside tbe intranet's domain. 

Figure. 23 illustrates this scenario. Suppose a node mi^ates from 
interface "d" to interface "g". Just supplying the MMS 102 local interfaces 
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would not allow access. The MES 1 04 needs a priori knowledge of the 
distributed interface. It can tiien select the necessary address to use on 
interface "g". The NAT 2000 will then do the appropriate translation of 
network address/port information on each packet to the internal interface 
5 "c" address. The reverse operation wiU happen on frames sent by the MMS 
102 to the MES 104. 

Example Policy Management and Location Based Services 

A further non-limiting embodiment of the invention provides the 
unique ability to offer additional security, cost savings, and services based 

10 on a number of metrics. Since the MMS described above is intimately 

involved with each application session the MES establishes, either sidle (i.e., 
the MMS and/or the MDBS) can apply policy-based rules to tailor and control 
the communications between the MES and its ultimate peer. It can further 
condition or modify applications request based on the locale or proximity of 

15 the device and its attachment to the network. For example, the MMS and/or 
the MES can include a rules engine that applies learned, statically defined, 
or other rules based on policy to each application session that is eistablished 
or request that is attempted. The MMS can further distribute some, none or 
part of such rules and/or processing to the MES to provide further metering 

20 or security against rogue attacks of the mobile device. Unlike certain other 
policy management technology available in a distributed topology, the 
MMS provides a central place to administer the rales and pohcy decisions 
and have them distributed to the remote device at any time during the course 
of a conversation/connection. 

25 The rules themselves can be configured based on user, user group, 

dievice, device group, process, appHcation identity arid/or network point of 
attachment. Once defined (learned), they cap be combined to govern and 
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control a variety of different events, activities, and/or services, including for 
example: ' 

• denying, allowing or conditioning ingress access to the remote 

::deviee; .■ 

• denyijQg, allowing or conditiomng access to specific network 
resources based on identity, 

• denying^ alldwing or conditioning access to available or 
allowable bandwidth, 

• denying, allowing or conditioning access to other network 
resbufcies and/or 

• modifying, conditiofldng or changingcdritent or infoixiiation^ 
Such dedsibhscaii be based 6ii any of various different factors including 
for example: 

• proximilyj location, altitude and/or other characteristics of the 
mobile device, 

• time of day, 

• application or process identity, address,, etc; 

• application behavior (e.g., bandwidth requirements); 

• current network conditions; and/or 

• other static or dynamic factors 

Furthermore by employing the distributed architecture, the MMS 
can also apply or share the same decision set. Having the MMS perform the 
policy mainagement processing and/or decision making may be desirable in 
instances where the mobile device has limited processing power to execute 
the engine or bandwidth limitations are applicable, or for security purposeis. 

Figure 24 shows an example table of the some metrics (rules) that 
might be used to control a sample MES. This table may be populated either 
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Statically or dynamically^ and maybe updated anytime before, during, or 
after the connectiOn/conversatipn. For example, a person could use a rules 
editor (e.g., a wizard) other mechanism to define entries in the table. In 
other example arrangements, the metrics could be automatically defined by 
5 the system based on learning, or could be dynamically changed based on 
changing conditions. The rules also have a priority assigned to theni 
whether implied by the location iri the table or specifically designated by an 
assignment. This priority allows the engine to correctly determine the 
expected behavior. AdditiLoaal user interface functions allow the system 
10 administrator and or user of the device to inteixogate the rules engine and 
test put the ftmctLpnality of a given rule set. 



which pohcy management decisions may be based, iucludiug: 

• MES Qonsmunicatipns capability (transmit Puly, receive pnly , or 



The Figure 24 exanaple table shows a number of example nuetrics on 



15 



transmit and receive); 



• Whether the MES request is proxied; 



• MES source port; 



• MES source address; 

• MES destination port; 



20 



• MES destination address; 



25 



• MES protocol; 

• Amount of bandwidth available; 

• Process name(s), identities pr other characteristics; 

• Network name(s), identities or other characteristics; 

• Location (e.g., GPS coordinates or other location information); 

• Network point of attachmbnt; 

• User identity name, identity or other characteristic; 
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• Other metrics. 

It will be appreciated that the invention should not be limited by the scope 
of the metrics entries in the example table as it is not meant to be an 
exhaustive list. The entries can be specific as in this example or use a 
5 generic mechanism (e.g., wildcards) to describe the desired behavior of the 
mobile node with regards to network access and entitlements. 

The Figure 24 example table further includes a "deny request" entry 
that indicates the result of a policy managemen t dec is ion to be made based 
on the metrics. As one example, the particular example entries in the Figure 

10 24 table specify that all comiections to destination ports 20 and 21 should be 
denied or throttled back if. the available bandwidth is reduced to less than 
100,000 bytes per second. Furthermore, in the particular example shown, 
rules (rows) 3 and 4 allow only network traffic to flow to and from the 
MMS (all other network traffic that is not proxied is implicitly discarded). 

15 In one example, before each RFC request or frame is processed, the 

rales engine is consulted to determine if the status of the operation. B ase on 
the outcome of this process, the request may be allowed, denied or delayed. 
Figure 25 is an example flowchart of steps that may be performed by the 
MMS and/or the MES to make policy management decisions. 

20 Furtheraiore by combining the roaming technology outlined 

previously with other location or navigational information that mat be 
available, the MMS. detects when a mobile end system has moved from one 
point of attachment to anotlicr. By combining this information in 
conjunction with the ability of the mobile end system to detect a change in 

25 environment of network topology, or locale enable the invention provides 
additional levels of location based monitoring and services. 

To fully realize the potential of this information, enhancements to 
both the Internet Mobility Protocol and RFC engine are outlined. Several 
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new RPC protocol and configuration enhancements wiE be added to provide. 
tMs fimctionaHty. These are listed bejow. 

Example Location Change RFC 

When the mobUe end system has determined that it has moved to a 
5 new point of attachment using interface assisted roaming or some other 
method such as detecting changes frp^n a global positioning system, it wiU 
send a formatted "Location Change RPC Request" message to its peer, in 
tMs case the mobiMly management server. The "Location Change RPC" 
formats one or more of the point of attachment identificatioii information 

10 into a t5^e, length, value fprma,t/T1ielOTe i^^ 

iidentificatiori infonnation, types, supported will include but will not be 
limited to 48 bit IEEE MAC Addresses, IPV4 Addresses, IPV6 Addresses, 
longitude, latitude, altitude, and attachment names in ASCII. The length 
indicates the length in b5'tes of the identification data, and the data contains 

15 the actual point of attachment identification. The mobility management 
server upon receipt of the "Location Ctmnge RPC Request" will build a 
"Location Change Alert" that contains tiie I>oint of attachment identification 
and other pertinent information such as the mobile end system 
identification, the user name, and FID. It tiien will forward the alert to the 

20 alert subsystem on the server. The alert will be formatted with the same 
iype, length, data format utilized within the "Location Change RPC 
Request". The alert subsystem will then forward the location change alert 
with this information to all applications that have registered for the alert. 
Applications that have registered for the alert may include monitoring 

25 applications such as tiie current active status monitor, a long-term activity 
log, the policy management engine, and other third party applications and 
network management tools. One such third party application noay combine 
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this location information with Web based niaps to provide detailed 
infonnation aboiit a mobiliB end systeni's or MMS location: In addition to 
such applications, other actions can be associated with location change 
alerts. This includes sending an email, printing a message, launching a 
5 program and/or change in policy. 

The Location Change RFC wUl contain a field in its header that 
indicates if it was triggered due to location change, distance change, or rate 
change. 

In some instances, the MES may not know it has roamed. Depending 
10 on the medium and the network adapter it is attached to, the MMS may be 
the only entity that notices that the MES has migrated to a new point of 
attachment. Consider the case of a mobile router. The addr esses behind the 
router stay the same, only the routers address changes. In this case, tlie 
MMS knows the new care of address of the MES. Therefore, for complete 
15 motion detection it needs to be a combination of the both the MES and 
MMS to detect motion. In the present embodiment, the MMS detects 
motion of the clients at the IMP layer when the source address changes and 
a new EVLP message is received. When this occurs, the MMS locally 
generates a Location Change Alert. It also sends a message back to the MES 
20 that its point of attachment has changed. 

Example Topology RFC 

The "Topology RPC Request" is sent firom. the mobility management 
server to mobile end systems. Upon receipt of this RPC the mobile end 
system will read the topology information stored in its local data store and 
25 build a Topology RPC Response. The Topology RPC response wiU be 
formatted with a Total Length Field followed by consecutive type, length, 
data point of attachment identification followed by type, length, value data 
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indicating the subnet and network information. This iofonnation may be 
used on the server to build a complete topological map of the mobile 
network being served Iby the server. 

Example Location information UI 

5 The user interface on the server will provide a method for mapping 

and displaying location information. This location information will be 
available for each active mobile end system and the long-term activity log 
will maintain a history of all active and previously active mobile end system 
location changes. The user interface will permit the system administrator to 

10 configure the point of attachment information in human readable form. For 
example, if the point of attachment information is provided in the form of a 
48-bit EEEE MAC address this MAC address will be displayed along with 
the information provided through the user interface on the server. If the 
point of attachment represented an access point in front of the "HallMark 

15 Cards" store it might be configured to present the following information 
"HallMark, Street Address, City, State,- Zip". When displayed to the user, 
information "HallMark, Street Address, City, State, Zip" is presented. 

Example Location RFC Timer 

A configurable timer is provided on the mobile end system to limit 
20 the rate at which Location Change RPCs may be sent from the mobile end 
system to the mobility management server. If the timer interval is larger 
than the rate at which the point of attachment changes are occurring, the 
mobile end system will wait until the timer interval expires before 
generating another Location Change RFC. 
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Example Distance Change Notificiation 

A distance metric will be provided for triggering the generation of 
Location Change RPCs. This setting configures the system to send an 
update when the user moves three dimensionally every n feet frorh, 
5 kilometer, or other appropriate unit of measure from tlie last point of origin. 
By default this setting is disabled. Enabling this setting causes a Ghjinge 
Notification when the distance interval in the cdnaguration is exceeded. 

Example Rate Threshold Notification 

A rate change metric will be provided for triggering the generation of 
10 Location Change RPCs. This parameter is configured in distance per second 
such as miles per hour. It will specify an upper and lower bounds and a time 
interval that the attained rate must be sustained (i.e. 0 MPH for 10 minutes 
or 70 MPH for 1 minute). When this speed is reached a Location Change 
Notification will be generated. 

15. ■ EXAMPLES • ■ 

The present invention finds application in a variety of real- world 
situations. For example: 

Intermittentlv Connected Portable Computer 

Many businesses have employees who occasionally telecommute or 

20 work from home. Such employees often use laptopi computers to get their 
work done. While at work, the employees typically connect their laptop 
computers to a local area network such as an Etliernet tiirough use of a 
docking port or other connector. The LAN connection provides access to 
network services (e.g., printers, network drives) and network apphcations. 

25 (e.g., database access, email services). 
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Now suppose an employee working ^^^^^^ 
for file evening and wants to resume working from home. The employee 
can "suspend" the operating system and applications running on the laptop 
computer, pa.ck up tiie laptop coniputer, and bring the laptop computer 

5 home. • 

Once home, the employee can "resum 
applications running on the laptop computer, and reconnect to the office 
LAN via a dialup connection and^or over the Internet. The Mobihty 
Management Server (which continued to proxy the laptop computer vis-a- 

10 vis the network and its applications during the time the laptop computer was 
teinpbrarily suspended) can re-iati^ 
corohiimiGating With the la^^ 

From the perspective of the employee now working from home, all 
of the network drive mappings, print servieeSi email sessions, database 

15 queries, and other network services and applications, are exactly where the 
employee left them at the pffice, Fqrthermore, because the Mobility 
Management Service continued to proxy the laptop computer's, sessions, 
none of those network applications terminated tlie laptop computer's 
sessions during the tune the employee was traveling from the office to 

20 home. The ip^vention thus ptdvides efficient persis^^^ 

the same or multiple network mediums that is very powerful and useful in 
this and other contexts. 

Mobile Inventory and Warehouse Application 

Imagine a large warehouse or retail chain. Within this campus, 
25 inventory workers use vehicle niounted (i.e., trucks and f orMifts) personal 
laptop computers and handheld data coUection uirits and teraunals to 
perform inventory management of goods. Warehouse and retail workers are 
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often inexperienced computer users that do not understand network sub-nets 
and require management supervision. The present invention allows the 
creation of a turnkey system that hides the complexity of the mobile 
network from the warehouse users. The users can move in and out of range 
5 of access points, suspend and resume their Mobile End Syistdins 104, and 
change locations without concem for host sessions, network addresses, or 
transport connections. Iti adiditioh, the manageinent software on the 
MobiHty Management Server 102 provides management personnel with 
metrics such as number of transactions, which may be used to gauge worker 
10 productivity. Management can also use the network sub-net and access 
points to deterinine worker*s last kiiown physical 

Mobae Medical Application 

Imagme a large hospital using radio LAN technology for network 
cbinmutdcations between several buildings. Each building is on a unique 

15 sub-net. The present invention enables nurses and doctors to move from 
robin to room with handheld personal computers or terminals — reading and 
writiag patient information in hospital databases. Access to the most recent 
articles onmedicatioh and medical procedures is' readily available tiirough 
the local database and the World Wide Web. While in the hospital, pagers 

20 (one and two way) are no longer required since the present invention allows 
continuous connection to the Mobile End System 104. Messages can be 
sent directiy to medical personnesl via the Mobile End System 104. As in 
the case with warehouse workers, medical personnel are not required to 
understand the mobile network they are using. In addition, the Mobile End 

25 System 104 allows medical personnel to disable radio transmission in area 
where radio ernissions are deemed undesirable (e.g., where they might 
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interfere with other medical equipment) — and easily resiime and reconnect 
where they left off . 

Trucking and Freight 

Freight companies can use the present invention to track iaventory. 
5 While docked at a warehouse, the Mobile End System 104 may use LAN 
technology to update warehouse inventories. While away firom local 
services, the Mobile End System 104 can use Wide Area WAN services 
such as CDPD and ARDIS to maintain real time status and location of 
inventory. The Mobile End System 104 automatically switches between 
10 network infrastructures — hiding the coraplexity of network topology from 
vehicle persomiel. 

Mobile Enterprise 

Corporate employees may use the system in accordance with the 
present invention for access to E-mail, web content and messaging services 
15 while within an enterprise campus that has invested in an infrastructure such 
as 802.1 1. The cost of ownership is reduced since pager service and other 
mobile device services are no longer required; The purchase of mobile 
infrastructure is a one time capital expense as opposed to the costly "pay- 
per-use" model offered by many existing mobile device services. 

20 IP Multiplication 

If an organization has a LAN that needs to be connected to the 
Intemet, the administrator of the LAN has two choices: get enough globally 
assigned addresses for aU computers on the LAN, or get just a fbW glbbaUy 
assigaed addresses and use the Mobility Management Server 102 iil 
25 accordance with the present invention as an address multiplier. Getting a 
large number of IP addresses tends to be either expensive or impossible. A 
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small company using an Internet Service Provider (ESP) for access to the 
Internet can only use the IP addresses the ISP assigns and the number of 
IP addresses limits the number of computers that can be on the Internet at 
the. same time. An ISP also chiarges per connection, so the; more computers 
5 that need to be on the Internet, the more expensive this solution becomes. 

Using the Mobility Management Server 102 in accordance with the 
present invention as an address multiplier could solve many of these 
problems. The enterprise could put the Mobility Management Server 1 02 
on hardware tiiat is connected to the Internet via an ISP. Mobile End 

10 Systems 104 could then easily connect. Because all connection to the 

Internet would go through tihe Mobility Management Server 102, only one 
address from the ISP is required. Thus, using the present invention as an 
addiress multiplier allows the enterprise to get just a few (in many cases one) 
addresses and accounts from the ISP, and allows the entire LAN to have 

15 simultaneous connections to the Internet (assuming enough bandwidth is 
provided). 

While the invention has been described in connection with what is 
presently considered to be the most practical and preferred embodiment, it 
is to be mderstood that the invention is not to be limited to the disclosed 
20 embodiment, but on the contrary, is intended to cover various modifications 
and equivalent arrangements included within the scope of the appended 
claims. 
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WHAT IS CLAIMED IS: 

1 . A mobile Gomputing network including at least one mobile 
computing device coupled to the network via a network point of attachment, 
characterized by a policy-management arrangement that applies policy 

5 naaiiagement rules based on yatious metrics including mobile cbmputing 
device location. 

2. A network as in claim 1 further characterized in that processing of 
the attributes of the rules can be distributed and. appUed at either the mobile 
computing device and or the mobility management server or both. 

10 3 . A network as in any of the preceding claims further characterized 

in that prioritization of the rules is either impMed by position in the entry in 
such table or explicitly noted by an ordinal ensuring the expected behavior. 

4. A network as in any of the preceding claims further characterized, 
in that datastore for the rule attributes is locally or centrally administered via 

15 central management services 

5 . A network as in any of the preceding claims further characterized 
in that behavior of a particular appUcation(s) is modified based on a number 
of metrics including cost of service, netwoirk point of attachment, trust 
relationship, etc. 

20 6. A network as in any of the preceding claims further characterized 

in that the effect of the behavior modification is to allow, deny or delay a 
request based on attributes of the rules. 



25 



7. A network as in any of the preceding claims further characterized 
in that even if the application is already started, a rule or set of rules is 
invoked to modify the application(s) processes. 
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8. A network as in any of the preceding cliaims further characterized 
in that ppiat of presenee information (locatipn) i? further used to govern 
appUcatipn behavior or provide relevant infonnation to the mobile 
computing device. 

9. A networfc as in any of the preceding claims further characterized 

in that rate of motion along with distance measurements is used to alter 
behavior of applications or the communication path. 

10. A network as in any of the preceding claims further characterized 
in that topological information is extracted and displayed as residt of the 
location information. 

1 1 . in a mobile computing network including at least one mobile 
cbniputing device coupled to the netwcarfc via a nelTPS'ork poini of attachment, 
an impxQveinent eorapriising ai interface-assisted roamiag listener that 
detejcts, based at least in part pn identification of the network point of 

. attachment, whether said rnobile computing device has roamed to a 
different network segment. 

12. A network as in claim 1 1 wherein said mobile computiug device 
includes a network interface adapter, and said listener obtains said network 
point of attachment identification from said network interface adapter. 

.13. A network as in claim 1 1 wherein said listener maintains a 
network topology map storing informalion that correlates said network point 
of attachment identification with furiher information concerning a network 
connection. 
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14. A network as in claim 1 1 wherein said listener detects when 
communications with said network is interrupted or reestablished. 
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15. A network as in claim 14 wherein said H^^ 
signal in response to detection Of (a) network conitoiM interruption 
and re-estabUshment, and (>) change of said network point of 

-identification. 

5 16. An interface-based listener for use in a mobUe computing 

device, said interface-based listener integrating information from at least 
one network interface adapter with information available from at least one 
network stack to determine whether said mobUe computing device has 
moved to a new network point of attachment. 

10 17. The interface-based listener of claim 16 including a network 

topology map providing network connection information including network 
points of attachment information. 

18. The listener of claim 17 wherein said Ustener dynamically 
constructs said network topology map based on learned information. 

15 . 19. The interface-based hstener of claim 16 including a status 

checker that checks status based on occurrence of an event. 

20. The interface-based hstener of claim 16 wherein said event 
comprises any of a timer timeout, a low level roaming driver callback, and a 
network level activity hint. 

20 21. The interfacerbased listener of claim 16 including a connection 

information searcher that queries an interface as to whether the mobile 
computing system has already visited the current network point of 
attachment. 
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22. The interface-based Hstener of claim 16 including a connection 
arrangement that registers or reacquires a current address to be valid on a 
new network segment, 

23. The interface-based listener of claim 16 including a roam signal 
5 generator that generates a roam signal in response to detection, based at 

least in part on information provided by an interface, that the mobile 
computing device has roamed to a different network segment. 

24. The interface-based listener or claim 23 further including a 
heuristic analyzer that determines whether a previously assigned address is 

10 still vahd. 

25. A method of determining whether a mobile node has moved to a 
new network point of attachment, comprising: 

(a) receiving network point of attachment identification information 
from a network interface; 

15 (b) using said network point of attachment identification infomiation 

to detemodne whether said niobile node has moved to a new network point 
of attachment; and 

(c) generating signaling in response to said step (b). 

26. A method as in claim 25 further including maLntaitrihg a network 
20 topology map, and using smd map to perform step (c). 

21. A method as hi claim 25 wherein said step (c) included 
generating a roam signal. 
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28. A melJiod as in claim 25 wherein said Step (b) include 
said network point of attachment information from a network adapter. 

29. A method as in claim 25 further including falling back to an 
alternative roaming detection mechanism if a network interface is not 
available that supports generic signaling. 

30. A method as in claim 25 further including selecting, at least in 
part in response to said network point of attachment information, between 
alternate network connection paths. 

31. A method for facilitating communication with a mobile system 
10 over disjoint networks comprising: 

establishing communications between a node and said mobile system 
over a first network; 

sending to the mobile system over the first network, data identifying 
the node on at least a second network disjoint from the first network; and 

15 using the data to estabHsh communication between the mobile 

system and the node over the second network. 

32. The method of claim 31 further including authenticating the. 
mobile system for authorization to communicate with the node over tiie 
second network before sending the data to the node over the first network. 
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33 The method of claim 21 wherein the sending step comprises 
sending distributed interface data to the mobile system over the first 
network. 
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34. A network as in eladm 12 wherein said EBLobile computing device 
network interface adapter is physically attached to liaid network. 

35. A network as in claka 12 wherein smd mobi^^ device 
connnimicates wirelessly with the hel^ork poitttp^^^ 

5 36. A method for maintainhig comniiinication between a mobile 

computing system and a network node as the mobile computing system 
roams between over plural disjoint networks comprising: 

estabhshingcoinmunicatibns between t^^ 
via a first network segment; 
10 sending the mobile computing system, via the first network s 

information for use in re-establishing communications with said node via 
plural further network segments each of which are disjoint from the first 
network segment; and 

using said iiifbimatioh to re-establish communications between the 
15 mobile computing system and the liode via any of said plural further, 
disjoint network segments. 

37. The process of claim 36 wherein said information comprises 
distributed interface data. 

38. A process for providing least cost routing in a network having 
20 plural disjoint segnients, comprising: 
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(a) estabHshmg coimrainications between the network 
temporarny-attaehed mobUe computing device; 

(b) using a roiaming mechanism, to 

mobile computing device to roam between said plural disjoint segments; 
.5 ■ and ■ 

( c) enforcing at least one policy parameter to enable efficient 

automatic selectidnof alternate valid network paths for re-establishing 

cGBcmnunication between the network and the mobile computing device ia 

response to mobile computing device roaming; 
10 39. The process of elaun 38 wherein the poUcy paranieter comprises 

an element selected from the following group: bandwidth; cost pet data unit 

and quality of service. . 

40. In a mobile computing network including at least one peer 
computing system and at least one mobUe coniputing device coupled tp the 

15 network via a physical link, an improvement comprising a server coupled to 
the network, said server prbxyihg coinmumcations between the niobiie 
computing device and the peer computing systeni so as to maintain a 
continuous virtual data stream connection between the mobile computing 
device and the peer computing system during times when the physical Unk 

20 to the mobile computing device is temporarily interrupted. 

41. A network as in claim 40 wherein said mobile computing device 
has a point-of-rpresehce address on said iietwork, said peeir cotiiputijttg 
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system conununieates with said server using a virtual address, and said 
server maps said virtual address to said pomt-of-prfesence address . 

42. A network as in claim 41 wherein said server detects when said 
mobile computing device has changed its point-of-presence address, and re- 

5 maps said virtttal address to isaid changed point-of-presence address. 

43. A network as in claim 40 wherein said server queues and 
responds to requests from said peer computing system on behalf of said 
mobile conaputing device during times when said mobile computing device 
is teinporarily unreaeha,ble or roajimi^. 

10 44. A network as in claim 40 wherein said server communicates 

with said mobile computing device using a conventional trarisport protocol. 

45. A network as in claim 44 wherein said server communicates 
with said mobile coniputing device usitig remote procedure c 

46. A network as in claim 44 wherein said server communicates 
15 with said mobile coniputing device using an Internet Mobility Protocol. 

47. A network as in claim 46 wherein said Internet Mobility 
Protocol provides for automatic removal of datagrams based on user- 
configurable timeouts. 

48. A network ds in claiih 46 whereiti said Internet Mobility Protocol 
20 provides for automatic removal of datagrams based on user-configurable 

retries. 

49. A network as in claim 40 wherein said server performs per-user 
policy management of consumption of network resources by said mobile 
computing device. 
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50. A network as in claim 40 wherein said server provides user^ 
configurable session priorities for said sessions of said mobile computing 
device. 

51. A network as in claun 40 wherein said mobile network includes 
5 plural sub-networks, and said mobile computing device uses Dynamic Host 

Configuration Protocol along with other niethodologies to allow said mobile 
computing device to roam from one of said plural sub-networks to another 
of said plural sub-networks. 

52. A network, as in claun 4Q wherein said server comprises a 
10 Mobility Management Server. 

53. A network as in claim 40 further including; at least one mobn^ 
interconnect coupling said mobile con:q)utitig devices to said server. 

54. A method of maintaining a persistent coimection with at least 
one mobile computing device in a mobile computing environment, said 

15 method including: 

managing at least one session between said mobile computing device 
and at least one further computing device, and 

maintaining the session when the mobile computing device becomes 
unreachable, suspends or changes network address. 

20 55. A method as in claim 54 further 

user configurable session priority for said session. 



56. A method as in claim 54 wherein said managing step includes 
managing consumption of network resources by said mobile computing 
device. 
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57. A metiiod as in claim 54 wherein tiie mobMe computin 
environment includes plural sub-rietwofks, and said maintaining step uses 
Dynamic Host Configuration Protocol to maintain the session when said 
mobile cdmputing device roams between said sub-networks. 

5 58. A method as in claim 54 

communicates datagrams with said mobile computing device and 
automatically removes unreliable ones of said datagrams based on at least 
one user coiifigurable parameter. 

59. A method as in claim 58 wherein said user cdnfiguf able 
10 parameter comprises a timeout. 

60; A method as in claim 58 wherein salid user configuf able 
parameter Gomikises a user configurable retry nmnber. 

61. A method as in claim 54 further including providing said mobile 
computing device with a variable point of presence address, and wherein 

1 5 said managing step includes mapping said variable point of presence 
address to a virtual address, the session being associated with the virtual 
address. 

62. A method as in claim 54 wherein said managing step includes 
using a Remote Procedure Gall protocol to communicate with the mobile 

20 computing device. 

63. A method as in claim 54 wherein said maintaining step 
maintains the connection state of said session during interruptions in a 
physical link connecting said mobile computing device with said mobile 
computing environment. 
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64. A method as in clBim 54 whereiii said managing step 
commiuiicating with said mobile computing device using at least one 
standard transport protocol. 

65. A method as in claim 54 wherein said mobile computing device 
5 includes plural application sources, and said managing step includes 

coalescing data from said plural application sources into a stream, and 
forwarding said stream. 

66. A method as in claim 65 furtiher including demultiplexing said 
coalesced data from said streani and forwarding said demultiplexed data to 

10 plural associated destinations. 

67. A method as in claim 65 wherein said stream includels frames, 
and said coalescing includes dynamically resizing said firanies to 
accommodate a maximum transmission unit of the mobile computing 
environment. 

15 68, A method as in claim 65 wherein said coalescing includes 

maintaining semantics of unreliable data, and selecting discarding said 
unreliable data based on said semantics. 

69. A method as in claim 54 wherein said managing step includes 
providing guaranteed delivery of rnessages to and/or from said mobile 

20 computing device. 

70, A method as in claim 54 wherein said managing step includes 
controlling which network resources are accessible by said mobile 
computing device. 
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7 1 . A server for maintaining a persistent connection with at least one 
mobile computing device in a mobile computing environment including at 
least one further computing device, said server including: 

a session manager that manages at least one session between said 
5 mobile computing device and said at least one further computing device, 
said session manager maintaining the session .when the mobile computing 
device becomes .unreachable, suspends or changes network address. 

72. A server as in claim 71 wherein said session manager includes a 
session priority queue that provides at least one user configurable session 

10 priority for said session. 

73vr A serveac as in claim71 wherein said session manage includes 
means for managing consumption of network resources by said mobile 
computing device. 

74. A server as in claim 71 wherein the mobile computing 

15 environment includes plural sub-networks, and said session manager uses 
Dynamic Host Configuration Protocol to maintain the session when said 
mobile computing device roams between said sub-networks, 

75. A server as in claim 71 wherein said session manager 
communicates datagrams with said mobile computing device and 

20 automatically reiiioves unreliable ones of said datagrams based on at least 
one user configurable parameter. 

76. A server as in claini 75 wherein said user config^able parameter 
comprises a timeout. . 

77. A server as in claim 75 wherein said user configurable parameter 
25 comprises a user configurable retry number. 
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7^. A server as in claim 71 wherein said mobUe compu 
environment provides said mobile com^ device with a variable point of 
presence address, and said session manager maps said variable point of 
presence address to a virtual address, the session being associated with the 
5 virtual address. 

79. A server as in claim 71 wherein said session manager uses a 
Remote Procedure Call protocol to communicate with the mobile computing 

. device. . 

80. A server as in claim 71 wherein said mobile computing 

10 environment includes at least one physical link connecting said mobile 
computing dcAdce with said mobile cpinputing enviroimient, ah 
session n;ianager maintains the connection s 
interruptions in said physicallink. 

81. A server as in claim 71 wherein session nianager cormnunicates 
15 with said mobUe computing device using at least one standard transport 

protocol. 

82. A server as in claim 71 wherein said mobile computing device 
includes plural application sources, and ssiid session manager coalesces data 
associated with said plural application sources jnto a stream, and forwards 

20 . -saidstream... ^. .-'l . J,- 

83 . A server as in claim 71 wherein said mobile computing device 
includes plural application sources, and said session manager demultiplexes 
coalesced data from said plural appHication sources and forwards said 
demultiplexed data to plural associated deistinations. 
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84. A server as in claim 71 wherein session manager communicates 
with said mobile computing device using frames, and dynamically resizes 
said frames to accommodate a maximum transmission unit of the mobile 
computing environment. 

5 85. A server as in claim 71 wherein said session manager maintains 

semantics of umeliable data, and selectively discards said unreliable data 
based on said semantics. 

86. A server as in claim 71 wherein s£dd session manager provides 
guaranteed delivery of messages to and/or from said mobile computing 

10 device. 

87. A server as in claim 71 wherein said session manager places 
controls on mobile computing enviromnent resources said mobile 
computing device can access. 

88. In a mobile computing environment including a proxy server, a 
15 mobile computing device that maintains a persistent virtual connection with 

at least one further computing device during times when the mobile 
computing device becomes unreachable, suspends or changes network 
address, said mobile computing device including: 
a transport driver interface, and 
20 a mobile interceptor coupled to said transport driver interface, said 

inobile interceptor intercepting requests for network services at said 
transport driver interface, generating Remote Procedure Calls responsive to 
said requests for network services, and forwarding said Remote Procedure 
Calls to said proxy server. 
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89. A mobile computing device as in claim 88 wherein said mobile 
interceptor includes a session priority queiie that provides at least one user 
configurable session priority. 

90. A mobile computing device as in claim 88 wherein said mobile 
5 interceptor includes means for managing consumption of network resources 

by saidmobile computing device. 

91. A mobile computing device as in claim 88 wherein the mobile 
computing environment includes plural sub-networks, and the mobile 
computing device ifmiher includes means for using D 

10 Configuration Protocol to obtain a point of presence address when said 
mobile computing device roan^ between said sub-networks. 

92. A mobile computing device as in claim 88 wherein said mobile 
interceptor communicates datagrams with proxy server and automatically 
removes unreliable ones of said datagrams based on at least one user 

15 configurable parameter. 

93. A mobile computing device as in claim 92 wherein said user 
configurable parameter comprises a timeout. 

94. A mobile computing device as in claim 92 wherein said user 
configurable parameter comprises a user configurable retry number. 

20 95. A mobile computing device as in claim 88 wherein said mobile 

computing device has an associated a variable point of presence address that 
said Mobihiy Management Server rnaps to a virtual address. 
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96. A mobile computing device as in claim 88 wherein said mobile 
interceptor uses a Remote ProCeKtee? Gall prbtoepl to coinmumcate with the 
said Mobility Manageinent Server. 

^^^^^^ 9^^^^ 

5 computing environment includes at least one physicaHlnk coimecting said 
mobile computing device with said mobile computmg environment, and 
said mobile interceptor receives updated connection state information of at 
least one session from said Mobility Management Server after an . 
interruption in said physical link. 

10 98. A mobUe computing device as in claim 88 wherein said mobile 

computmg deyice includes a standard transport protocol handler, and said 
mobile interceptor communicates with said Mobility Management Server 
via said standard transport protocol handler. 

99. A mobile computmg device as in claim 88 wherein said mobile 
15 computing device includes pluial application sources, and said mobile 

interceptor coalesces data associated with said plural application sources 
into a stream, and forwards said stream to said Mobility Management 
Server. ' 

100. A mobile computing device as in claim 88 wherein said mobile 
20 computing de^^ 

interceptor demultiplexes coalesced data from plural application sources 
and forwards said demultiplexed data to said plural application destinations. 

101 . A mobile computing device as in claim 88 wherein mobile 
interceptor communicates with said proxy server using frames, and 
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d)aiainiGally resizes said frames to accommodate a maximum transmission 
unit of the mobile computing environment. 

102. A mobile computing device as in claim 88 wherein said mobile 
interceptor maintains semantics of unreliable data^ and selectively discards 

5 said unreliable data based on said semantics. 

1 03 . A mobile computing device as in claim 88 wherein said mobile 
interceptor provides guaranteed delivery of messages to and/or from said 
proxy server. ' 

104. A mobile computing device as in claim 88 wherein said mobile 
10 interceptor places controls on mobile computing environment resources said 

mobile computing device can access. 

105. A mobile computing environment comprising: . 
at least one mobile computing device including: 

a firansport driver interface, and 

15 a mobile interceptor coupled to said transport driver interface, , 

said mobile interceptor intercepting requests for network services at said 
transport driver interface, generiating Rernote Procedure Calls responsive to 
said requests for network services, and forwarding said Remote Procedure 
Galls to at Ifeast one proxy server; 

20 said proxy server including at least one work dispatcher that receives and 
himdles said Reniote Procedure Galls forwarded by said mobile interceptor, 
said proxy server including a proxy queue that proxies a virtual session on 
behalf of said mobile computing device when the mobile computing device 
becomes temporarily disconnected from said mobile computing 

25 environment. 
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106/ In a mobile eomputing network i^^ 
computing device coupled to the network via a network point of attachment, 
an improvement comprising an interface-assisted roaming listener that 
detiscts, based at least in part on identification of the network point of 
5 attachment, whether said mobile computing device has roamed to a 
different network segment. 

107. A network as in claim 106 wherein said mobile computing 
device includes a network interface adapter, and said listener obtains said 
network point of attachment identification from said network interface 

10 adapter. ; 

108. A network as in claim 106 wherein said listener maintains a 
network topology map storing information that correlates said network point 
of attachnient identification with further information concerning a network 
connection. 

15 109. A network as in claim 106 wherein said listener detects when 

communications with said network is interrupted or reestablished. 

1 10. A network as in claim 109. wherein said listener generates a 
roam signal in response to detection of (a) network communications 
interruption and re-establishment, and (b) change of said network point of 

20 attachment identification. 

111. An interface-based listener for use in a mobile computing 
device, said interface-based listener integrating information from at least 
one network interface adapter with information available from at least one 
network stack to determine whether said mobile computing device has 

25 moved to a new network point of attachment. 
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1 12. The interface-based listener of claim ll 1 including a network 
topology map providing network connection information including network 
points of attachment information. 

113. The listener of claim 1 12 wherein said listener dynamically 
5 constructs said network topology map based on learned information. 

114. The interface-based listener of claim 111 . including a status 
checker that checks status based on occurrence of an event. 

115. The interface-based listener of claim 111 wherein said event . 
comprises any of a timer tiineout, a low level roaming driver callback, and a 

10 network level activity hint. 

116. The interface-based listener of claim 1 1 1 including a 
connection information searcher that queries an interface as to whether the 
mobile computing system has already visited the current network point of 
attachment. 

15 1 17. The interface^based listener of claim 1 1 1 including a 

connection arrangement that registers or reacquires a current address to be 
valid on a new network segment. 

118. The interface-based hstener of claim 111 including a roam 
signal generator that generates a roam signal in response to detection, based . 

20 at least in part on information provided by an interface, that the mobile 
computing device has roamed to a different network segment. 

1 19. The iaterface-based listener or claim 118 fm-ther including a 
heuristic analyzer that determines whether a previously assigned address is 
still vahd. 
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120. A method of determining whether a mobile node has moved to 
a new network point of attaclment, comprising: 

(a) receiving network point of attaclment idefiitif ication information 
from a network interface; 

5 (b) using said network point of attachment identification information 

to determine whether said mobile node has moved to a new network point 
of attachment; and 

(c) generating signaling in response to said step (b). 

121. A method as in claim 120 further including rnaintainitt 
10 network topology map, and using said map to pesrfonn step (c). 

122. A method as in clahn 120 wherein said step (c) includes 
generating a roam signal. 

123. A method as in claini 120 wherein said step (b) includes 
obtaining said network point of attachment information from a network 

15 adapter. 

124. A method as in claim 120 furtlier including falling back to an 
alternative roaming detection mechanism if a network interface is not 
available that supports generic signaling. 



125. A method as in claini 120 further including selecting, at least in 
part in response to said network point of attachment information, between 
alternate network connection paths. 
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